Search the Community

Goal: Find the best methods (or at least some good options) for message decoupling that are simple to implement and efficient to execute. Background: Messaging architectures in LabVIEW that use a class for each unique message type are strongly coupled to the recipient process (aka ‘Actor’). This is due to the need within the message execution code (a method of the message class) to access the private data of the recipient process or to call methods in the recipient process in order to do the work that the message intends. (See Actor Framework for an example of this). The problem arises when you wish to send these messages across a network between two separate applications. In most cases, these applications are not duplicates of each other, but rather serve completely separate purposes. An example would be a client and a server. The client needs to message requests to the server and the server needs to push data to the client. For a process to send a message, it needs to package the inputs in the private data of the message class and then transmit it via the network transport (which can be implemented in multiple different ways and is not material to this discussion). In order to construct the message, the sender will need a copy of the message class included in their application. This will mean they will need to also load the class of the message recipient since it is statically linked to the message class within the method that executes the message. And since that will trigger many other class dependencies to load, the end results is the majority of the classes in the recipient application will need to be included in the sending application. This is not an optimal solution. So, we need to find a way to decouple messages from their recipients but still be able to execute them. My solution: The way I have been handling this is for each message that needs to cross the network I create a message class whose execute method calls an abstract method in a separate class (call this my network message execution class). Both the sender and the recipient will have a copy of these message classes and the network message execution class. Inside the message class’s execution method, I access a variable that stores an instance of the network message execution class and then calls the specific abstract method in the network message execution class for this particular message. In each recipient application, I create a child of the network message execution class and override the abstract methods for the messages I intend to receive, placing the actual execution code (and static links to the recipient process) within the child class methods. Finally, when each application initializes, I store its child network message execution class in the aforementioned variable so it can be used to dynamically dispatch to the actual method for message execution. The advantages of this are: Messages are decoupled between my applications. The disadvantages are: For each message I wish to transmit, I must create a new message class, a method in the network message execution class and a method override with the real implementation in the recipient’s network message execution class child and then edit the message class to call the method in the network message execution class. This also means that each application must have a copy of all the message classes passed between applications and the network message execution class. The problem arises when you add a 3rd or fourth application or even a plugin library to the mix and wish to decouple those from the other applications. You must either extend the current set of messages and the abstract methods in the network message execution class, having each entity maintain a copy of all of the messages and the network message execution class even though they never send or receive most of those messages, or you must add additional variables to your application to store different implementations of the network message execution class for each link between entities. So, now that you have read my long explanation, does anyone have ideas for a better way to solve this? I would love to simplify my code and make it easier to maintain, while retaining the functionality that class based message architectures offer. But decoupling must be addressed somehow.