Publish / Subscribe
NHS Digital | February 2017
In many cases, the nature of the information sharing is event based – i.e. triggered by an activity that has occurred in a health or care service. Details of the event are published by the Event Source (typically a health or social care system) and sent into an Event Hub for onward propagation. Other services are able to express an interest in receiving copies of events that meet criteria, which they can define in the form of a “subscription”. When the hub receives an event from a publisher it matches it to subscribers and sends it to them in real time.
Examples of events that might be sent in this way could be Birth, Death, Hospital Admission, Immunisation, etc. but could technically be anything that needs to be proactively sent on to interested parties.
Subscriptions typically fall into one or more of the following types:
- Topic-based: In a topic-based pubsub service each published event is associated with a single topic. A topic is also sometimes referred to as a group, channel or subject. A subscriber can subscribe to all events associated with a particular topic. Topic-based pubsub is the oldest form of subscription model and the simplest to implement. It is also the most constrained, as you can only subscribe to a coarse grained topic.
- Content-based: In a content-based pubsub service, a subscription language is provided to allow a subscriber to define filtering criteria based on the content of events. The subscription language will allow the combination of attribute names and attribute values using a set of operators into a filter expression. Any events published that match the filter expression will be delivered to the subscriber.
- Type-based: In a type-based pubsub service, each event is treated as an object that is an instance of a specific type or class. The type will have a formal definition including attributes (properties) and possibly methods. A subscriber can subscribe to a particular type (similar to a topic) and also define a filter expression based on the type attribute values (similar to filtered-topic and content-based), where the filtering is done within the pubsub engine. This approach lies between the simple topic-based approach and the complex content-based approach.
- Can support immediate proactive notification or alerting of events to subscribers.
- Well suited to events that many recipients (subscribers) need to be made aware of.
- The event publisher does not need to know who the interested parties are – they can publish the event and rely on the event hub to identify the recipients based on the subscriptions it holds. This allows more flexibility for re-shaping and re-configuring health and care services without all event producers needing to have knowledge of the shape of the services that will consume the events they publish.
- Can support multiple channels for delivery of events from the hub to subscribers – and the channel to use can be specified by the subscriber. For example, one subscriber may be able to recieve an event over a direct API call into their system, whereas another subscriber may want to receive it over MESH or eMail.
- The decoupling of the sender and receiver means that all parties must use common standards for content and structure to ensure subscribers can safely process events sent by publishers.
- There is no simple way of providing reliable delivery – the event producer does not know which subscribers need to receive the event, so they cannot easily track when all receivers have actually received the event they publish.
Was this article useful?4