Understanding Pub Sub

Home » Understanding Pub Sub

One of the big amendments in Domino V11 is pub sub. It brings a lot of potential, but only with the proper understanding of how to leverage it. It's a concept many Domino developers may be unfamiliar with, but one that has a lot of parallels in web development.

  • In Vert.x there is the Event Bus.
  • In React, Redux is a common approach to the event bus paradigm, although it provides a lot more.
  • Web sockets is the same kind of pub sub process, with browsers or other endpoints registered to be notified as appropriate.

But in Domino development, it is not a consciously typical approach in application development. It may also be a concept some Domino developers struggle to get their head around, because it's so different from the standard event coding paradigms. But as you'll see, there are examples where it exists in Domino.

First, let's break the process down into its basics:

  • There is a central place through which all interactions go, for asynchronous processing.
  • Code runs to pass a message to the central location, including all relevant information required for processing and a reference so the result can be retrieved. It also waits to process the response.
  • Separate code is put into a listener or handler to act upon the message and return a response. That needs registering to the central place.
  • Multiple listeners or handlers could be registered, so a single message could be used to perform multiple actions.

The complexity here is that code runs that sends a message into an apparent black hole. Working out what happens next is not obvious for the uninitiated.

It's also completely different to how much Domino code is written. Developers can typically trace through the functionality in a linear fashion and all that code exists in a single place or is directly references. Something like agent.run() defines which agent to run, and a call to a function in a LotusScript Script Library again makes it clear where to go next. But with the pub sub or event bus approach, it's less obvious what happens next. The code doesn't tell you where to go. You need to work out what's listening for the message - and it's possible that could vary depending on runtime scenarios.

But it's not a paradigm that's totally foreign to Domino developers. Think of scheduled agents. They're not listeners per se, but there is certainly a disconnect between the code that queues documents for processing (e.g. in saving a document or an action button) and the code that processes them (in the agent).

That's not the closest paradigm though. Think of mail rules, which run when mail is received. In agents, there are specific events that can be used. "Before new mail arrives", "After new mail has arrived", "After documents are copied and pasted" and "When documents are pasted". All listen for certain events and act accordingly, separately from whatever code causes a Notes document to trigger the event. The Database Script area is another, with things like "querydocumentdelete" and "postdocumentdelete". But they're a lot more straightforward, for various reasons:

  • they're much more rarely used
  • they're easier to identify, because they're in a specific area and not common
  • they are automatically registered as soon as they're saved. There is no conscious awareness from the developer that they're registering a listener for a message in a message queue

This means that when a development technology requires the message queuing or event bus paradigm, it's unfamiliar to developers. It also means the pub / sub functionality available in Domino V11 may be under-used, because it's a different approach and an unfamiliar paradigm to current development. But it's one that, when used effectively, could transform Domino development and integration beyond the platform.

6 thoughts on “Understanding Pub Sub”

  1. I’m looking forward to the pub/sub model, but it will be a big shift in thinking for Notes developers. One other parallel that might help reach them is the event model in LotusScript for forms, not because it is really that similar, but because it is much more commonly used by developers. I’ve had to tackle this thinking for developers with events triggered in our Midas LSX because they are less linear than form events. (For example, in generating HTML, every time a large enough chunk has been generated, an event is triggered and goes off and deals with the chunk.) But the idea that zero, one, or more handlers might be watching for a published event… that’s going to be a big logical leap for many.

  2. Frank van der Linden

    Good article. Will it also work with Kafka, the defacto in Event Bus in my world.
    And not only React and Redux use pub/sub, every asynchronous framework does. Like
    VueJS, Angular. In the Java it is Reactor project

    1. I’m not sure how the pub sub works. Earlier in the year the presentations at user groups talked about a standard message queue format, with one or possibly two message queue implementations. I believe RabbitMQ was one of those mentioned.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top