The previous blog post by Petri Kettunen provided insights on the Message Room use case study conducted by the University of Helsinki. This is the first part of a series of blog posts about the Message Room concept, and it provides an introduction to synchronous and asynchronous data exchange. The second part concentrates on life-event-based services and potential implementation alternatives. Three alternative implementation approaches are discussed in more detail in the third part.
In 2020, NIIS conducted an X-Road feature study to identify the needs and challenges of X-Road operators and members in Estonia, Finland, and Iceland. Information was gathered via 20 interviews (26 participants) and supplemented with an online questionnaire in Estonia (29 respondents). In addition, two innovation workshops were organized to collect further details on selected topics.
Messaging patterns were one of the topics included in the study. Currently, X-Road only supports synchronous request-response messaging. Still, the need for asynchronous messaging had been recognized based on user feedback and some new use cases, such as proactive life event-based services. Therefore, additional information and insights on the actual needs and requirements were needed to make more concrete plans regarding the next steps.
Synchronous and asynchronous messaging
An excellent way to understand the difference between synchronous and asynchronous messaging is to compare a phone and an email. A phone call is synchronous – both parties must be available for it, and you have to wait for an answer when asking questions on the call. Instead, an email is asynchronous – you can send an email when you want, and the recipient is free to choose when to read it and respond.
Currently, X-Road is based on synchronous communication suited for real-time data and document exchange. Synchronous data is exchanged via request-response pairs. On a simplified level, a service consumer sends out a request and then waits for a service provider's response. When the request is sent, the service consumer waits for the response until it is received or a timeout occurs. Synchronous messaging creates a tight coupling between the data exchange parties since the consumer is always dependent on the availability and performance of the provider. Also, changes on either side easily break down the connection.
In the case of asynchronous messages, a service consumer sends a request and continues processing other tasks. The service provider sends a response later once it has processed the request or, depending on the type of asynchronous messaging pattern, it may not send a response at all. Asynchronous messaging creates only a loose coupling between the data exchange parties, making them less dependent on each other.
From message exchange patterns to communication patterns
In practice, there are several message exchange patterns how asynchronous messaging can be implemented. Asynchronous messaging can be one-way or two-way, and it can be based on different combinations of push and pull, for example:
send a message with no response (push)
send a message with no response (pull)
send a message with an asynchronous response (push and pull)
send a message with an asynchronous response (pull and push).
The asynchronous message exchange patterns and their different combinations are used in various communication patterns. The publish-subscribe and message queue communication patterns were included in the X-Road feature study together with the asynchronous request-response message exchange pattern.
Asynchronous request-response
A service consumer sends a request and continues processing with other tasks. The service provider sends a response later once it has processed the request. The consumer may include in the request a destination for the provider to send a message with the response.
Publish-subscribe
A service provider publishes messages (publisher), and any number of service consumers will receive them (subscribers). Service consumers that are interested in a publisher’s messages “subscribe” to a predefined channel that they know publishers will be sending messages to. When an event happens, a message is sent to all the service consumers who have subscribed to the channel. Many publishers and subscribers can use the channel, and each message is delivered to all the subscribers.
Message queue
A message queue is an asynchronous communication channel where service producers and consumers do not interact simultaneously. Service producers push messages onto a queue, and consumers read the messages from the queue. Only one consumer gets a particular message, no matter how many consumers read messages from that queue. Many producers and consumers can use the queue, but each message is processed only once by a single consumer.
What do the users truly desire?
According to the X-Road feature study results, the publish-subscribe pattern is the most preferred option for implementing life-event-based services. Also, according to the MoSCoW methodology, it’s a MUST together with asynchronous messaging. Instead, message queues and data streaming were mentioned in the study as well, and they were considered essential by many participants. According to the MoSCoW methodology, they were both SHOULD.
After the feature study, interactive innovation workshops were organized with participants from Estonia, Finland, and Iceland. According to the results, the publish-subscribe pattern got the highest priority in expanding X-Road's current message exchange capabilities. Also, the results strengthen the image of the pattern's role in implementing the proactive life event-based services. Therefore, it is logical to concentrate on the publish-subscribe communication pattern. However, it doesn't mean that the other alternatives are forgotten or mutually exclusive. In the long term, different options remain open even if the publish-subscribe pattern is prioritized first.
Also, the goal is not to replace the currently supported synchronous request-response pattern with asynchronous messaging. Instead, the aim is to extend X-Road’s messaging capabilities with asynchronous messaging.