Pub/Sub in AF ?

[Dmitry]

I could not find a definite answer to this in the forum, so a couple of questions to AF enthusiasts from a non-AF developer:

1. How often do you find a need in using Pub/Sub on your AF Projects ?
2. What would be a good (i.e. simple & SOLID-compliant) way to implement it ?

Thanks,

Dmitry

[AristosQueue(NI)]

How often? Never within an application. I consider pub/sub to be useful (even critical) across networks, but at this point I consider it to be an anti-pattern within an application. 

[AristosQueue(NI)]

Since I would only consider pub/sub for network connection, what API I used would depend upon interoperability requirements with non-LabVIEW systems.

If my app is a subscriber, I would probably have one subVI called in my root actor that registers my needs with the server. Then I’d have (either A) a simple helper loop in root actor or B) a nested actor) that listens for messages from server and turns them into messages for my root actor. 

If my app is a publisher, then I may have one or multiple nested actors publishing out value changes to the server in the places within my app where those values change. I’m unlikely* to have just one actor whose job it is to publish state unless there’s some protocol requirement that many value changes be packaged together. If that req exists, messages will percolate up to the actor that can see the coherent state, which will then publish them out.

[CaseyM]

Also on the "never within an application" train.

[drjdpowell]

Just a side comment but the AF does actually use a type of Pub/Sub, in it's various "zero-coupling" techniques.  But this is a very local application of the principle, applying only to Caller-Callee interactions.  Dmitry's ArT stuff is a global Message-Broker Pub/Sub which can connect anyone to anyone.  

[Dhakkan]

---

@AristosQueue(NI) wrote:

How often? Never within an application. I consider pub/sub to be useful (even critical) across networks, but at this point I consider it to be an anti-pattern within an application. 

---

Do you consider the scenario of a LabVIEW host application communicating with a cRIO attached to the host PC as 'within an application' or 'across networks'?

During a not-so-recent project, I did wish for the capability to have topic-based pub/sub capability, so that:

• In case of a detectible network interruption, the host application and cRIO, both, would resume connection from the last set control values without additional coding.
• The multiple UI panels of the host application, each with its own data subset requirements, would subscribe to desired topics.
• Only the currently active UI panel would have ability to publish values.

Using my limited knowledge, I ended up having my root actor be the 'broker'. This definitely has opportunity for design improvement. Suggestions would be very welcome for me to consider for a future project.

[AristosQueue(NI)]

None of the AF zero-coupling connection techniques allow for arbitrary connections. A protocol handshake is not a pub/sub pattern. Claiming it as a degenerate pub/sub is highly misleading in my opinion. 

[AristosQueue(NI)]

> Do you consider the scenario of a

> LabVIEW host application

> communicating with a cRIO attached

> to the host PC as 'within an

> application' or 'across networks'?

Host to cRIO is network, but being network doesn’t mean sub/pub necessarily. I only mean there are network scenarios where pub/sub is critical, not that it is always the solution. 🙂 Your use case sounds like a good one for that. 

[drjdpowell]

---

@AristosQueue(NI) wrote:

None of the AF zero-coupling connection techniques allow for arbitrary connections. Claiming it as a degenerate pub/sub is highly misleading in my opinion.

---

It's a minor bugbear of mine that perfectly good english words get highjacked to only refer to specific technical things, including aspects unrelated to the original english meanings.  I know you and Dmitry are talking about using a message broker, but an outsider might not.  And it complicates talking about non-broker-based publication and subscription designs.

[AristosQueue(NI)]

---

@drjdpowell  non-broker-based publication and subscription designs.

---

I don’t think I’ve ever heard the term outside of such systems. As far as I’m concerned, pub/sub is message brokering, by definition. A service publishes its information and clients subscribe for updates. What else is there?