AF and publish / subscribe to topics

[SpaghettiCoder]

I want to throw a publish/subscribe concept for AF in the ring, mainly for discussion, hints and thoughts.

Please have a look at this proof of concept: https://github.com/kleinsimon/LV-Actor-Pub-Sub

Background:

I needed the ability to build rich applications with many actors and modular gui actors around a set of base actors (control, view, ...) I needed to modify per application .

I first took the message routing approach, but the complexity soon made the application hard to extend.

So I investigated the public api of the message queues and remembered the good old pub/sub concept, which usually works nice together with (micro)services.

I know that this is not canonical to the AF concept, but it has some benefits:

• No actor has to know the complete hierarchy. This is exceptionally nice for reuse actors
• The same actor type can be used for different tasks by subscribing to different topics
• Topics can relate to interfaces, actor types of messages (with their fqn). This way a sender knows, that his audience is compatible to the message it sends.
• You can extend the application by adding senders and receivers
• You don't have to keep track of enqueuer references
• The starting order of your actors does not matter
• You can better integrate dynamically started or stopped actors
• Decoupling of actors with a shared interface
• Channel behavior can be altered (retaining, load balancing, etc)
• Messages can be serialized and sent via other protocols
• Overall complexity is lower compared to message routing

Drawbacks I can think of:

• More overhead
• Topic names must be known. This can be worked around by convention: always use a interface as the receiver
• The source of a message is not traceable. If you want to know the sender, you have to include it in the message

Any thoughts about this?

[BertMcMahan]

This sounds somewhat similar to this one:

https://www.zyahsolutions.com/blog/af-msg-forwarding-utility

It might be worth listing some comparisons between the two. (I haven't had a chance to use either toolkit, but they sound like they solve similar problems).

[CaseyM]

Background:

I needed the ability to build rich applications with many actors and modular gui actors around a set of base actors (control, view, ...) I needed to modify per application .

---

Let me see if I'm on the same page as you here. I think what you're saying is that you have a set of actors that you'd like to reuse across multiple applications, but the challenge is that you're finding that they end up being coupled to messages specific to each distinct application. Because of this you're thinking that maybe a pub/sub approach is beneficial because it decouples the reusable actors from the application-specific messages. Is that more or less it?

---

I know that this is not canonical to the AF concept, but it has some benefits:

• Overall complexity is lower compared to message routing

Is it? Maybe in the amount of code you need to write once, but as far as developer readability, I often find it more difficult to trace and debug where messages originate from when the actor tree messaging scheme is avoided.

AQ had some thoughts on this recently as well.

I think there are other ways to achieve the reusability you're aiming for without needing to shortcut the standard AF messaging tree. In fact, I'm working on something like that currently. Once I'm able to test this more and make sure it works the way I expect, I'd be happy to share it.

[CaseyM]

---

@BertMcMahan wrote:

This sounds somewhat similar to this one:

https://www.zyahsolutions.com/blog/af-msg-forwarding-utility

It might be worth listing some comparisons between the two. (I haven't had a chance to use either toolkit, but they sound like they solve similar problems).

---

The modifications I referred to in my other post are exactly to this utility. We were struggling with this generic reuse challenge as well and the current implementation the Zyah Forwarding Utility relies on inheritance to determine the message routing which doesn't extend well to other applications.

Again happy to discuss in more detail if people have questions and I hope to have more updates soon.

[Oli_Wachno]

Not having really read the above:

Regarding Pub/Sub and Message Brokers, are you aware of Dmtry's presensation at the last GLA Summit?

https://youtu.be/MuPN4vqmO5c

[SpaghettiCoder]

About the relation to the message forward utility: this one, as far as I can get it, abstracts the message routing for an actor. My approach is not bound to a specific actor..

Also my intention was not only to reuse single actors, which is already doable using interfaces, but subsets of the hierarchy.

Let me try to explain this:

I have a control actor, which is the root actor. It handles updates to the model and starts actions using messages. I also have some device actors, which are partly exchanged for different applications (like a Hal). I also have an optional View Actor, that updates a View model, which is visualized by a bunch of panel actors.

This base application represents the abstract concept of a measuring method and the accompanied algorithms and sequences of actions.

I now take this base application and extend it for specific implementations, say some additional gui elements and a slightly different process.

With the concept of subscription, I can simply subscribe my new gui actors to the topics they should react to. I can also inherit my base actors and override the actions I want to modify. Also I can extend my model to integrate data, I don't care about in the reused base application. I can modify the hierarchy and add additional layers.

Regarding the readability: I think, it depends. My actors subscribe in the initialization to topics bound to interfaces. So I can always see, which messages I can expect. I also have a VIM that checks if the interface is implemented by the actor, so I can be sure, that they can be handled. Also, one can monitor the messages that go through a topic.

[SpaghettiCoder]

AQ had some thoughts on this recently as well.

I think there are other ways to achieve the reusability you're aiming for without needing to shortcut the standard AF messaging tree. In fact, I'm working on something like that currently. Once I'm able to test this more and make sure it works the way I expect, I'd be happy to share it.

---

Yeah I followed this discussion because at this time I was confused about the way messaging was supposed to happen in complex hierarchies.

I first took the advise and wanted to stick to the raw AF concept, but was very unhappy of how it worked out in my growing application.

Keeping track of the enqueuers and keeping the routing up to date was really hard and cumbersome. Also debugging began to be hard. And I found it hard do document actors, that should relay messages they self did not care about (gui-gui main-view-control-device). From the reusability point of view, this lead to the fact, that actors had dependencies for messages they only needed to route to their connected neighbors.

Maybe the last point was one of the most important. Because using the message broker as a third party, you can keep the dependencies bound only to the actors that really handle them. How else would I make the reuse part of my application take care of messages, that were introduced in the extension?

Maybe I did it wrong with the original concept. It is hard to find real life examples for bigger applications. Additionally, the AF is rather low level, which makes it somehow universal, but I don't think that any bigger application uses it without some abstraction layer.

Edit:

the word broker is misleading, because in my implementation each channel runs asynchronously and independent of other channels. The central part is more a registry, that keeps references to the channels and their assignments to the topics.

[SpaghettiCoder]

---

@Oli_Wachno wrote:

Not having really read the above:

Regarding Pub/Sub and Message Brokers, are you aware of Dmtry's presensation at the last GLA Summit?

https://youtu.be/MuPN4vqmO5c

---

No, I missed this one... Sounds interesting I will need to look at it in detail.

[CaseyM]

Lately I've spent some time reworking the Zyah AF Forwarding Utility and I think it's ready for a beta release. If you'd like to check it out as an alternative to classical pub/sub methodologies, send me a DM and I'll send you the VIP. (I don't want to publish it publicly on the forums since it is still a beta.) If anyone is a part of the AF Guild Discord (link in my signature) it's available there as well.

This new version uses registration instead of inheritance to determine what to forward and which direction to forward it within the AF Msg tree, but it uses the Msg tree 100% behind the scenes (no shortcutting) so you get to keep strictly-typed Msgs and don't need to learn any new message protocols or transport layers. Our goal was also to improve the API so it's easier to incorporate into your existing actors.

Happy to provide more details if people are interested.