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.