Page History

...

The general reasons behind the need for a message ordering are:

• guaranteeing the order of messages 
  • controlling the correct order is important to stay in sync between sending and receiving registry
  • some messages only make sense if processed in the correct order
• making transparent (no) messages are missing
  • in a perfect world this would not be needed and the current timestamps + reference codes would be sufficient. However e.g. in the case that the receiving registry collects messages from the queue, but looses those messages afterwards in a fully automated system, they will not know (in all cases) messages are missing, and even if they do, they might not know which ones. 
  • proper sequencing will make error handling and issue tracing easier

...

Message ordering will be realized by:

Option A):

intrinsic ordering only:

...

• A central sequence number provided by SMC. This sequence number will be drawn from a separate sequence per receiving registry.

For the message ordering to work properly there are different responsibilities with the different parties invovled:

• Sender responsibility:  

The sender is responsible for ensuring the desired order of calls to the Connect APIs.  If

...

Receiver Responsibility:  The receiver is responsible for monitoring the availableMessages queue and process retrieval calls to the Connect APIs in the order specified.

Pro:

• no additional information needed (ordering based on timestamps and incoming order SMC service)

Con:

• only implicit ordering
• no explicit indicator on missing messages on receiver side

Option B):

ordering via local sequence number:

Sender Responsibility: The sender has to add a receiver specific sequence to each and every message.  

Receiver Responsibility: The sequence number would be part of each message itself . The receiver has to check that the sequence number is correct (no number missing) and only process the messages if that is ok. Otherwise go back to the central system and claim the missing message.

Pro:

• most detailed information as the number is part of the whole communication proess

Con:

• alot of overhead in the communication
• extra work at each registry
• each registry has to maintain a sequence number for each new registry (peer to peer behaviour)
  • extra work for each registry when a new registry is added to the system
• error prone as independent implementations are needed and no control by the centralized system

Option C):

central sequence number provided by SMC:

option C1: one sequence per receiving registry

option C2: one number per sending / receiving registry combination

Sender Responsibility:  

...

API calls are to be scheduled / batched, it is suggested that the sender maintain a queue of outgoing calls / messages so that message sequence is persistent in the event of system failure. Make sure the next message is sent only when the status of the previous one has been marked OK by SMC.

• Central system responsibility: 

Central system provides the sequence number as part of the meta block as answer in each connect message (messages to another Registry).

Option: not add it to the message_response (and others)?

...

Central system provides the sequence number as part of the meta block in the message retrieved by the recieving registry.

• Receiver responsibility: 

The sequence number would be part of the meta block. The receiver has to check that the sequence number is correct (no numbers missing) and only process the messages if that is ok. Otherwise go back to the central system and claim the missing message.

Pro:

• • avoid peer-to peer problem
  • least effort needed on registry side
  • receiver can re-request "missing" message
    • can be automated, no help needed by WMDA staff
• allows for different levels of details (C1 vs. C2)

Con:

...

2.0.1

How to collect all messages at keep the sequence:

...