RE: designing a sane pubsub system

Jakab,

I do have a tale to tell but it is on implementing a system that was based on the idea of PubSub from wx rather than actually using it but may make clearer some of the advantages of such a system – if this is not of interest please stop reading now.

At work (so I can’t be too specific) we have a system where there are multiple cards, each running multiple processes with one card, (the modem), acting as a central communications hub and the processors on each card all running, amongst other processes, a message gateway. (All fairly standard so far). Obviously there are multiple messages that need to be routed to specific destination, be they cards (where they will go to the gateway process), or to other processes on a card via the gateway process.

The traditional approach for this is to have a dispatch table that specifies which messages go to which processes  on which cards – nice and clear but this means that every time that a new process is added, an old one deleted, a new message is added or a process is found to need to receive the information in a given message for some reason the tables in the gateway will need to be edited. Additionally there are about 20 card variants which have differing processes running and different message routings. This is a project that has a long lifetime, (currently it has been running for 10 years in development and production and is contractually due to be maintained for at least another 30 years)! There have been a lot of changes to the potential messaging – I am talking many 100s of such changes.

We implemented a “pub/sub” like approach where the individual processes, on start-up, send a fixed format message to the local message gateway to register their interest in specific messages. The identifier of the interested process is added to a list of destinations for that message, (there may be more than one). Incoming messages are looked up to see if there is a handler for that message and if there is none an no handler error reply is sent – if there is then a copy of the message is sent to each subscriber.  The advantages:


  1.  In the last 10 years the message gateway code has had only a dozen or so changes. (The overall code is at revision number 7000+ the interface control document that defines the message structure at revision 1100+)
  2.  The gateway doesn’t care/worry about message content – message IDs & sizes are embedded in the message header.
  3.  We can dynamically add a process, have it register for handling some messages and we are good to go – great for debugging or special use cases.
  4.  There is a fixed pattern for team members to follow when creating a process and registering which messages they need to “see”.
  5.  We have had a team that is spread around the world working on multiple branches of the code but we have not had any message routing conflicts.

I would encourage you to seriously consider the pub-sub pattern.

Steve

From: [email protected] <[email protected]> On Behalf Of Jakab Gábor
Sent: 31 May 2020 14:01
To: wxPython-users <[email protected]>
Subject: [wxPython-users] designing a sane pubsub system

Dear Group,

I'm working on a large-ish project that implements the MVC pattern. I use only pubsub for messaging between the components.

Building a sane pubsub system is something I struggle with - I always have the feeling that it lacks a basic idea and until now I could not find a basic principle or structure I can follow. Thus the pubsub system tends to be a seemingly random, tangled mess connecting the parts of a system with a quite clean design.

I'm aware that the question I ask is a very general one that can't be answered in a few words. Do you know of any source on basic ideas or recommendations for the design of a pubsub system?

Thanks in advance for any ideas.
--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>.
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/8320cb95-0c99-4257-9ed9-44ceff927269%40googlegroups.com<https://groups.google.com/d/msgid/wxpython-users/8320cb95-0c99-4257-9ed9-44ceff927269%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/VI1PR03MB447960C02CA9BD29556A09549B8D0%40VI1PR03MB4479.eurprd03.prod.outlook.com.