Broker Api Redesign

HAPI-FHIR requires a message broker to provide asynchronous messaging services for

• subscription processing
• mdm processing
• batch processing

Prior to HAPI version 8.2.0, HAPI-FHIR's broker api was built on top of Spring Messaging, a Spring API for JMS, a 1990s Java API for asynchronous message processing. HAPI ships with the simple Spring in-memory implementation of this API.

Since that time, a number of new message broker paradigms have emerged that have moved the industry away from JMS.

In release 8.2.0, HAPI-FHIR decouples the message broker services from Spring Messaging. SpringMessaging adapters are provided for backwards compatibility.

The new API largely mirrors with Spring Messaging API, with a few important differences. Here is a mapping from the old API to the new API.

Old New	Notes
ca.uhn.fhir.jpa.subscription.channel.api.IChannelFactory ca.uhn.fhir.broker.api.IBrokerClient	Creates producers and consumers
org.springframework.messaging.Message ca.uhn.fhir.rest.server.messaging.IMessage<T>	ResourceModifiedJsonMessage used to implement Message now it implements IMessage<ResourceModifiedMessage>
ca.uhn.fhir.jpa.subscription.channel.api.IChannelProducer ca.uhn.fhir.broker.api.IChannelProducer<T>	send() return value changed from boolean to ISendResult
org.springframework.messaging.MessageHandler a.uhn.fhir.broker.api.IMessageListener<T>
ca.uhn.fhir.jpa.subscription.channel.api.IChannelReceiver a.uhn.fhir.broker.api.IChannelConsumer<T>	Every IChannelConsumer<T>now has exactly one IMessageListener<T> associated to it

One significant change with the new API is that consumers and listeners now store the type of messages they expect to receive. Consumers are expected to validate the received message type before calling their listener. Generic typing on the new classes and methods will help with this enforcement.