GLA Summit 2022 Presentation: Context-Agnostic Actors

[Dmitry]

Abstract
Reusing properly engineered code saves time and money. Applying SOLID Design Principles results in creating highly reusable code units. Actors are the typical building blocks of Distributed Applications. Actors interact with each other by sending and receiving Messages.

Actors developed with the knowledge of location (within the Distributed Application) and/or ‘details’ of other Actors are not truly reusable. In such systems, moving an Actor into a different location or different Development Environment (i.e., Programming Language) takes time and effort not only for updating code of the Actor being moved, but also code of the Actors it communicates with.

This presentation shows how to future-proof Distributed Applications by creating Context-Agnostic Actors interacting via a LabVIEW-based Distributed Message Broker.

The PowerPoint 2016 file has some animations and is best viewed in Slide Show mode. It also has a large amount of Slide Notes that are essential for better understanding this presentation.

PDF file includes slide notes. To see notes either hover over an icon in the top left corner of a page (containing Notes) or right-click the icon and select “Open All Pop-ups” option. Diagrams & images on slides with animations are stacked and may obscure images farther out along Z axis.

Enjoy,
Dmitry

[drjdpowell]

Hi Dmitry,

How do you handle the fact that a network connection is unreliable, and a remote application may not be running or may stop?  This is different from the case of a local actor, which can be reliably communicated with.  

[Dmitry]

---

@drjdpowell wrote:

Hi Dmitry,

How do you handle the fact that a network connection is unreliable, and a remote application may not be running or may stop?  This is different from the case of a local actor, which can be reliably communicated with.  

---

There are two parts to this:

a) what is done by the Distributed Message Broker (DMB)

b) what should be done by the Application running on top of DMB (because different applications may care about different issues and it is not possible/practical to have DMB support all use cases)

What is handled by ArT Distributed Message Broker:

1. A Distributed Application runs in 2 or more "containers" (such as .EXE or LV IDE Project)
2. Each container has a local instance of DMB that is created prior to inter-connecting its Actors
3. Each DMB instance on startup creates and runs as many Message Gateway Actors as specified by the application (one per remote container connection). Connection details are normally stored as DMB setting in the application INI file
4. In current DMB version I use NI Network Streams to push messages across container boundaries. I might create another flavor using gRPC early next year
5. All connectivity issues (establishing initial connection and re-connecting after any failure) are handled by Network Streams
6. On establishing a Network Stream [re-]connection, Message Gateway "connects" the two DMB instances by sending a sequence of Subscription Requests to the remote DMB instance (which does the same thing). This is possible because the local DMB instance is in charge of keeping Topic Subscription lists for its application. Remote container may or may not have Actors publishing messages to these topics, but if it does - you are guaranteed to start getting messages from the remote container
7. When a local DMB instance gets a new Subscribe to Topic request - it subscribes the local Actor and also forwards this request to all active Message Gateways - which, in turn, forward them to connected remote containers
8. Upon receiving a message from the remote Message Gateway, the local Message Gateway instance forwards it to all local subscribers

With this design any messages published by a remote actor while the two containers do not have a connection are lost to any local subscriber (i.e. my DMB does not guarantee message delivery - which might be important for some distributed applications).

Depending on specific application requirements, the application code may:

• Monitor container connection status (by calling its local DMB instance) and alert user or the application SCADA subsystem on its connectivity status or go into a 'safe' mode until all connections are [re-]established
• Actors may use a 'heartbeat' message to make sure their critical remote counterparts are online prior to interacting with the remote container

[drjdpowell]

Do you have a feature analogous to the "State Notifications" in Messenger Library?  That is where late-subscribing clients are automatically sent a copy of the latest publication on a topic.  I find this helps a lot with unreliable TCP connections, as though individual notifications can be lost one can rely on getting the latest state when connected again (without any application code being required).

Another question: do you have Request-Reply?  Can you effectively Command a remote actor do do something and get a reply that confirms it is done, before proceeding with your next action?

[Dmitry]

---

@drjdpowell wrote:

Do you have a feature analogous to the "State Notifications" in Messenger Library?  That is where late-subscribing clients are automatically sent a copy of the latest publication on a topic.  I find this helps a lot with unreliable TCP connections, as though individual notifications can be lost one can rely on getting the latest state when connected again (without any application code being required).

Yes, I do support it and as you've pointed out it is a very handy feature 🙂 But one can disable it on a per-subscription basis if it gets in your way. A use case for disabling it would be:

1. I use Topics to implement 1:1 Actor-Actor private messaging (Caller to Nested and vice versa)
2. Topic lifespan is not related to Actor lifespan. Once a Topic is created - it hangs around until the application shutdown or some entity explicitly calling Message Broker to destroy such Topic
3. At some point an Actor can be requested to Stop by sending it a Stop command. It can be re-started later - using the same Topic Name. In such case - the new Actor instance would get the cached Stop message as the first command and shut itself down. Took some time to figure this out 🙂

---

@drjdpowell wrote:

Another question: do you have Request-Reply?  Can you effectively Command a remote actor do do something and get a reply that confirms it is done, before proceeding with your next action?

---

Yes, I do support this with a Blocking Request Message. I think it may be safely used in several use cases without risking a deadlock. Back in 2018 I gave a 7x7 presentation at the CLA Summit (in Austin) called Actors - Loosing the Ease of DataFlow Programming.  

Abstract:

Actors are Message Driven Entities. NI Actor Framework Best Practices discourage using Blocking Reply Messages as a leading reason for application deadlocks. As a result, Actor Programming is being reduced to implementing low-level Sequence Diagrams - losing lion’s share of the ease of Structured Data Flow Programming so dear to our hearts. Presentation discusses an important (and safe) use case for Blocking Reply Messages that allows bringing Data Flow back into our Actors.

Summary:

1. Decision to design and implement business logic with asynchronous messages makes code hard to design, read and understand (low level programming)
2. Blocking messages keep us in the Data Flow domain (higher level)
3. Properly using blocking messages does not lead to Deadlocks
4. Do not let yourself become a victim of common misconceptions !!!

I am sure a number of people on LabVIEW discussion groups would strongly disagree with this 😮