Universal Publisher Actor

[PrimaryKey]

Hello all,

I was thinking about this for quite some time. I want to build a generic, reausable Publisher Actor that would implement Subscribing, Unsubscribing and Updating functionality. The Updating would take the list of subscribers, extract the Publication they are interested in, process that Publication and send back the Result.

No matter how I tackle the topic I cannot seem to get arund the need for a generic data type, like a string or variant for the Reply. I want to create Zero Coupling based solution. I can sucessufully create Zero Coupling for the Publications (they can be defined as behaviors of a child Publisher and sent during Subscription) and the Replies ( they also can be specified during Subscribing) but I cannot get away from sending a variant in the Reply data.

I'm thinking now that the best solution would be to use Reply Messages from AF, and I'm wondering if in this special case they would be safe. I think they would be because I'm not actually waiting for them to be processed in the original actor, but rater they are subscribed for, processed at Update speed and then sent back.

I'm attaching a little different code, where i tried a different approach - Publications specified during subscription have string arguments and the processing returns string results. This processing mechanism is limited though, because it only dynamically dispatches based on the Publisher actor. Lots of issues with this, I know

Please let me know what do you think about the first approach I described - with Reply Msgs

Maybe someone already wrote a Universal Publisher Actor?

[Fire]

H Piotr Please have a look at https://github.com/HB-GSI/CSPP.  The CSPP_Core submodule contains in CS++ProcessVariables two passive data classes PV.lvclass and AE.lvclass (Alarm & Event). It also includes a PVConnection base class enabling to read from and write to a PV. Derived classes implement the concrete network protocol. DataSocket is supported by default, since it is also available an Linux. CS++SharedVariable.lvlib contains the shared variable implementation.  CSPP_DSC supports DSC features to create SV programmatically and subscribes to SV change events.  CSPP_DIM supports the DIM communication (www.cern.ch/dim)  A caller actor registers PV/AE to a PVMonitor which dispatches registered messages to the observer actor. A PVProxy.lvclass enables registering of PV by configuration. Event the protocol to be used can be set by configuration.  I am very interested in feedback.  Holger

[drjdpowell]

Piotr_Kruczkowski wrote:

No matter how I tackle the topic I cannot seem to get arund the need for a generic data type, like a string or variant for the Reply. I want to create Zero Coupling based solution.

Your generic type can be a class hierarchy.  A "Data object" or "Data message" contained inside your Command messages.  I illustrated a system (in Messenger Library rather than the AF) of published Data Messages wrapped in Command-Pattern Messages here on LAVA.  There the issue was to use Comand classes not loaded on the publishing remote system, but the same principle applies here, I think.

[PrimaryKey]

I was thinking about making it into a class, but then I thought that it achieves exactly the same thing as a variant. Especially if the variant is used as a basis of an abstract zero coupling msg, because you can put parsing that variant into the receivers DO method. This just adds another class hierarchy for data which is not used anywhere else in the app, so it doesn't look elegant. I think variant or string would be more elegant.

[drjdpowell]

Piotr_Kruczkowski wrote:

Lots of issues with this, I know

The biggest issue to my mind is that you have a periodically-called "Process Publication" method, rather than a "Publish" method that is called immediately after anything has changed.  This affects message ordering, since immediately-sent messages may get ahead of publications of state changes that happened previously.  If A happens then B, then you want all publications resulting from A to be sent before any messages sent by B.

I had a similar problem with my publication system, which was originally handled by a helper actor.  Publications ("Notifications") were sent via the helper, and thus could fall behind directly messages sent soon after.  I reworked the system to ensure preserved ordering of messages.

Please let me know what do you think about the first approach I described - with Reply Msgs

Sorry, I didn't understand that.  AF "Reply Msgs" are only usable synchronously, so I don't see how they apply in an asynchronous notification system.

[PrimaryKey]

I just meant that Reply Msg not used to impose synchronous communication, but instead as a basis for this asynch notifications could be good.

But I think I finally found a nice solution to this. I will post the code soon with examples