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.
Good article, Jason Gary will be presenting on this at CollabSphere 2019 next month. I think the Pub/Sub is very important to the future of Domino.
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.
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
Good question. We’d like to use this with VueJS also.
…and thanks Paul for this good article, again!
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.
where can I read more about the pub/sub feature?