Durable Subscription in an Older Aircraft System

Durable Subscription in an Older Aircraft System


An older message framework that I designed seems like it must have anticipated Durable Subscription. That is, each instance of a message was delivered. The messages were delivered to components of the application in the local processor or to components of the application of a remote processor of a dual processor system.

However, in that system there was a controlling application and a service application. Only the controlling application could initiate request messages when the supplying component was in the remote processor. However, it could initiate a delayed or filtered content request; that is, it could send a request for a periodic response or one to be triggered when a given value was matched. Then the service application could send the response message back to the controlling application where the framework would distribute it to the requesting component or any others that had registered for it.

The delivery of messages to other components within an application was the same in both applications. Rather than a queue for each component, there was one framework request queue. The top message of the FIFO queue was popped from the queue and then delivered to each requesting component of the application in turn in a priority order where the priority was configurable for each message topic. After a component had run, the message was delivered to the next component that had subscribed for it.

A message topic subscribed by a remote application component could be either synchronous or asynchronous. That is, the framework of the originating controlling application would either wait for the response from the remote component before proceeding or continue without waiting. For a filtered content request topic from the controlling application component to a component of the remote application, the request had, of course, to be asynchronous.