Quick introduction to how all of this will work

The message definition

The messages that will be queued will contain a combination of meta data and the actual event, it will be something like this:

<eventMessageEnvelop id="12451245">
    <insertDate>2010-01-20</insertDate>
    <retention>
        <days>10</days>
    </retention>
    <eventName>http-tempuri-com/myApp/V1.2/someAction</eventName>
    <eventMessage>
        .........
    </eventMessage>
</eventMessageEnvelop>

The root queue

All messages of which the ordering should be preserved (aka a functional group) will be queued in what we call the “root” queue by sending them to the InitiatorService. The API to this “root” queue is a stored procedure (PublishEvent Stored Procedure). All queued messages use the same dialog id.

By default there is no stored procedure activated on the RootService of the root queue.

Adding subscribers

Adding a subscriber is as easy as calling the AddSubscription Stored Procedure and providing it with an event name and subscriber name. For each subscriber that is added we will create 2 new queues, 2 initiator services, 2 receive services, 1 stored procedure and start 2 new dialogs. Event names can be added by calling the same AddSubscription Stored Procedure.
2 queues are added:
  1. one that will contain all messages for the given subscriber (= all messages where the event name is in the list of event names for the subscriber)
  2. one that will hold all messages (that are not deleted because of retention rules) and which will act as the new source for future subscribers
1 stored procedure is generated:
The same stored procedure that is being used by the RootService is generated for the new Subscriber Service, however it is not (yet) activated.


Is this all?

No it is not, this is a work in progress. For more information take a look at the rather complete introduction blogpost

Last edited Jul 30, 2010 at 7:06 PM by TimMahy, version 10

Comments

No comments yet.