Content Filtered Topic Added to Exploratory Project

Content Filtered Topic Added to Exploratory Project


As mentioned that I would on September 1, I have added the Content Filtered Topic feature mentioned in The AIDA System, A 3rd Generation IMA Platform, DIANA Project White Paper to my exploratory project.

With a pat on the back for myself in regards to my design and implementation, adding this feature took from sometime in the afternoon of September 1 to begin thinking about what I would need to do to having a running application yesterday afternoon while averaging maybe 5 hours a day at doing so. Not too bad if I do say so myself.

In this implementation, I also added an Aperiodic activation method for a component to eventually replace the pseudo periodic method. The difference is that in the Aperiodic method the component is run via the Message Controller framework so that the forever loop is part of the framework as well as the delay to continue the loop and again invoke the component after the interval specified when the component registered itself with the framework. This removes the need for the component to know the means that are necessary to provide the delay or that there is a forever loop involved.

In regards to the new Content Filtered delivery style, having the forever loop in the framework also allows the framework the ability to free any message buffers for topics read during the just completed execution of an Aperiodic component and remove them from a delivery queue for the component.

I figured that components that would be requested to filter the content that they produced before publishing what met the criteria of the requesting component would likely need to run at a particular interval rather than be event driven when notified of the publication of a topic.

Before adding the Content Filtered feature, a requesting component could only be assured that its consumer received a particular instance of a topic was if the delivery was point-to-point and the consumer was event driven such as with the N-to-One delivery method. A component that ran at specified intervals could only read data flow delivered topics where the component received the most recent instance of the topic. If multiple producers, the latest instance of one producer would replace that of an earlier producer as the one that the consumer would read. Therefore, the filter conditions of one requestor could be lost if another requestor published a request after that of the first and before the consumer had a chance to run.

Therefore, I added a delivery queue to the framework for each registered Aperiodic component that would allow the Content Filtered requests of each requesting component to be queued awaiting the execution of the request consumer; that is, the producer of the requested content.

In my implementation, if a requestor publishes multiple requests during the interval from one execution of the Aperiodic component and the next, the second is to replace the first in the queue. However, the requestor will most likely fail to obtain a write buffer for such a second request and so won’t be able to publish it until the first has been read.

The requesting and producing components must have a “contract” with each other as to what the filter conditions can be with the producing component keeping track of the various conditions and only publishing the response topic for a particular requestor when the conditions that it specified have been met. Therefore, it must maintain a table that identifies the requesting component by its private key, the topic that is to be published, and the conditions that have to be met to publish it. The request topic (Ada package or C# class) identifies the conditions while the response portion of the topic identifies the content to be included in the response. The request must identify the requesting component, the scope of the request (cancel, every time the conditions are met, only the first time, etc), and the condition pairs where each pair has the equality condition (Equal, Less Than, Less Than or Equal, etc) and the value to satisfy the condition.

Each time that the Aperiodic component reads the topic, the framework marks the oldest request in the queue as read and then provides the pointer to the topic buffer. The component can then save the request conditions. Before finding any oldest request in the queue, the framework checks for any previously read requests and releases the topic buffer of such a request and removes the request from the queue. Thus, if the Aperiodic component reads the topic until there is no instance of the topic to be returned, the queue will be emptied and each requestor’s buffer will be released for it to use again.

Both the reading and writing to the queue are, of course, done in a thread safe manner. In case the Aperiodic component doesn’t empty the queue, the framework will also check for previously read requests and release the topic buffer and remove the request from the queue when the component has finished running and control has returned to the forever loop of the framework.

It is assumed that the requestor wants its own version of the filtered topic. That is, the filtered content that it requested. Therefore, the response is delivered point-to-point to the requestor in the same manner as N-to-One. Only it is delivered each time that the content satisfies the specified conditions rather than immediately following the read of the request topic.

The contract between the requestor and the producer could, of course, be different. That is, there could be one requestor that specified the conditions that would be used by the producer as the criteria for publishing a corresponding data flow topic that could be read by any subscribing component. This could be indicated by the use of a request topic that didn’t supply the identity of the requestor. Or, a Content Filtered topic could be used as a means of providing data to an Aperiodic component if a more controlled delivery than data flow was needed.