Navigating the Actor Framework.pptx

[Ryan_Griffin]

Actor Framework slides from the July 25, 2013 PLUG+ user group meeting.  Motivates using the Actor Framework for applications with parallel processes that need a standard communication framework, and how the Actor Framework maps to the Queued Message Handler architecture. Major topics include:

• Hands-on navigation of existing AF lvproj files
• Step-by-step instructions for how to create a basic Actor Framework project from scratch or from the LabVIEW 2012 templates
• Walkthrough of adding Actors and Messages to an existing AF project
• Brief introduction to LabVIEW project methods for navigating LVOOP (show class library, show class hierarchy,
• Additional Actor Framework resources, including a link to the NI webcast that introduced the mapping from QMH to AF

[Nate_Moehring]

I'd like to discuss further the question that Phillip posed near the end of the presentation:  What is the purpose of the Do method [if all it does is call other methods]?

I'm sure others can provide a more complete answer to this question, and I hope they will.  But 2 things that come to my mind in response to this question.

1. By sending a message object from one actor to another, you are changing the location of action, or changing where the code is actually executed, from one actor (while loop) to another actor (while loop).  That is the basic purpose of the message, to get something done somewhere else, to request information from somewhere else, or to receive information from somewhere else.  Another technique for doing this is to use by reference method calls, but then the location of action is in the requesting actor, and you end up with a very synchronous and tightly coupled system.
2. The Do method is the underlying mechanism that allows a generic message-receiving-loop to accept and process any message [that inherits from the base message class] via dynamic dispatching.  "Do something, whatever it is your going to do."  The receiver does not necessarily need to be modified to accept new messgaes.  Moreover new messages can be added to a system without even stopping the actor, that's pretty cool.

Complete sidebar, but one thing I think the Actor Framework currently lacks is an easy way to cross Application Instance boundaries.  The message queues have limited scope.  Network capability can be built into your system by creating "gateway actors", no doubt.  But it would be nice if there was a native way to send a message to an actor running on a different machine or application instance running on the same machine. Even better, take advantage of the built in security features of VI Server, at a minimum.  Some prototypes have been demonstrated by NI, but it doesn't seem to be high priority to make it part of standard Actor Framework.

[AristosQueue (NI)]

Do.vi also provides a place where the message can do custom handling. For example, the Batch Msg.lvclass uses its Do.vi to execute a loop of all the internal messages' Do.vi. There are also messages that may need to call multiple methods on the actor in a row. This is uncommon for classes designed as actors from scratch but does happen on classes that are being retrofitted to be actors.

Regarding the sidebar: on ni.com/actorframework, please check out both of the network actor approaches.

• The linked network actor pattern is a way for one actor tree to communicate with another remote actor tree where the two trees are independently running -- like a host connecting to an already running RT system (yes, AF deploys fine onto RT). This network style works with the LV 2012 actor framework without modification.
• The nested network actor pattern is a way for an actor tree to *seamlessly* deploy itself across multiple machines simply by specifying an Application Instance in the Launch Actor.vi. The caller and callee have no idea that they are operating on different machines. This allows for distributed computing processes to be modeled with actors. This requires a slightly rev'd version of the framework (fully backward compatible) which is available on the forums and which will ship with LV 2013. The nested network actor pattern is considered experimental -- it is tested only in toy projects thus far with no reports of anyone attempting to use it in production code for us to collectively be confident of its scalability. I would love for someone to validate this approach and inspect my code.

You mention that this does not seem to be a high priority to make it a part of standard AF. You are correct insofar as I only push changes into the official LV version of AF after community feedback and adoption confirms the approach. Having said that, the framework that ships with LV 2013 is fully sufficient to support such networking if you want to use mine or Allen's or write your own. It was a priority to enable the possibility of such communication. It has not been a priority to promote any one particular style unless/until we are confident of that style.

Are they prototypes? Or open-source libraries? 😉

[Nate_Moehring]

That's great!  Thanks for your thorough reply.  I don't closely follow the AF forums so I was unaware of the recent effort put into networking actors.  I'm glad to hear this capability will be shipping with LV2013!