Service-Oriented Architecture Attributes Progress Report 2

Service-Oriented Architecture Attributes Progress Report 2

The use of the Queued attribute has been extended in the Exploratory Project framework to be more general along with implementing the Queue Size attribute.

Since the Queue Size attribute is a Subscription Attribute, it is used by a particular consumer subscribing to a topic.  Therefore, the queue of published topic instances yet to be read by a consumer component is not just one queue for a component but a set of queues, one for each queued topic subscribed to be read by the component. 

Therefore, a change was made so that each such consumer of the topic was provided with a queue of the requested size and the single queue for a consumer was removed.  Presumably a consumer that is to be run at a slower rate will request a longer queue to avoid losing instances of a queued topic.

Note:  Topics that are published very frequently where only the latest instance is needed by a component will continue to use a Most Recently Published topic rather than a queued one to avoid the processor cycles necessary to make extra copies.  One analysis of a Flight Management System found that such copies are a significant source of CPU loading. 

Also note that the lack of extra copies only applies to components within the same application.  Two extra copies will be necessary for each remote application that needs to receive the Most Recently Published instance of the topic but not extra copies for multiple components within the remote application.  This could be avoided if a common memory could be used by the applications so that the producer could write to it and the various consumers could read the MRP instance via the pointer to its buffer in the common memory.

Although I have retained the Pseudo Periodic component Activation attribute, since it was previously implemented, it can’t have the framework release any final buffer instance.   That is, the previously read buffer is released when the component does a new read.  But when the component doesn’t drain the queue by reading until there are no more entries to be read, the last entry read won’t be released until the component continues after the delay.  This is because a Pseudo Periodic does its own delay and doesn’t return to framework after it is first started.  Thus the framework cannot release the last entry that was read as it can when an Upon Demand, Periodic, or Aperiodic component finishes running and returns to the framework to await the next time it is invoked.

Getting the new queued topics changes debugged took longer than I had thought it would.  This was because I used two chains of linked elements to keep track of the consumers with queued topics and the particular topics with read queues for a consumer.  This resulted in a structure illustrated as follows.

 Consumer Queue Anchor

    |

    |  Consumer Q Chain     Consumer Queue        Read Q Chain

    |     +------+          +-----------+          +------+

    +---->| Item |--------->| Read Q Ptr|--------->| Item |---> Read

          |------|      /   |-----------+          |------|     Queue C

       +--| Next |     /    |   Key 2   |       +--| Next |

       |  +------+    /     +-----------+       |  +------+

       |             /                          |

       |            /                           |  +------+

       |      Consumer Queue                    +->| Item |---> Read

       |         Addr/Ptr                          |------|     Queue B

       |            \                              |   0  | <-- end of

       |             \                             +------+     chain

       |              \

       |  +------+     \    +-----------+          +------+

       +->| Item |--------->| Read Q Ptr|--------->| Item |---> Read

          |------|          |-----------+          |------|     Queue A

          |   0  |          |   Key 1   |          |   0  |

          +------+          +-----------+          +------+

The Consumer Queue Anchor points to the beginning of the Consumer Queue Chain.  Each link of the Consumer Queue Chain has an Item that points to the data of the link and a Next pointer to the next link of the chain.

Each entry in the Consumer Queue is pointed to by an Item of the Consumer Queue Chain.  This set of data records each has the key of a particular consumer for which topic instances are queued and an anchor address/pointer providing the location of the Read Queue Chain of the consumer.

Each link of the Read Queue Chain has an Item that points to the Read Queue for a particular topic that has its published instances queued for the consumer and a Next pointer to the next link of the chain.

For each of the two types of chains, a null (0) Next pointer indicates the end of the chain.

Also, note that the links are added such that the chains will be read in LIFO order.

For some reason, although I had numerous examples of the code required to add links to a chain I had difficulty following my examples.  A sign of getting old?  Hope it was just temporary. 

Next will be to create more example components with various methods of activation and more example topics with various methods of message exchange and use them to subscribe to various combinations of most recently published and queued topics to more completely debug the modifications of the SOA attributes.