PUBLIC COMMENT PERIOD - Application Sequencing and Recovery Proposal

, ,
1

Imported from previous forum

2

he EMEA/Americas Global Technical Committee reviewed the Application Sequencing and Recovery Proposal. The specification now enters into a 15 day public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Committee will meet to review public comments before final approval.

Please post feedback, comments, and questions as replies to this discussion thread.

A link to the Application Sequencing and Recovery Proposal (MS Word format) can be found at

http://fixprotocol.org/documents/3682/FIX%20Gap%20Analysis%20Application%20Sequencing%20and%20Recovery%20v060.zip

The Public Comment Period closes on November 23rd, 2007

3

[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Comments:

  1. Chapter 4.7 mentions ApplFeedID (1180) - but the field is proposedly renamed to ApplID (1180) according to revision notes and Message tables. Renaming of existing fields rarely occur, is it considered OK as the field is introduced in another post-5.0 extension pack?

  2. The third paragraph of 4.7 mentions “Session level should be exempt from using these fields …”. Assume the text should read “Session level messages should be…” (i.e. add “messages” to sentence).

  3. The last paragraph of chapter 4.7 has a bullet point of “2. Request to see the AppLastSeqNum sent from an application”. This raises the question of support for “heartbeats” at the application level and if there is a need for an “end-of-file” indication per application. Relevant especially in cases where multiple feeds from a a set of publishers are consolidated into a single one. Repeating queries to verify that no new last message is missed seems a doubtful design metaphor.

  4. Chapter 6 in the bullet list mentions “ApplFeedID (1180)”, should be “ApplID (1180)” if the field is renamed

  5. I still think the use of “Appl” is confusing as ApplVerID (1128) and other session level fields including “Appl” refers to an entirely different concept than the “Appl” used in this proposal. (I know, I don’t have a better proposal)

  6. The rules of the fields in the Standard Header are not complete. ApplSeqNo, ApplLastSeqNo and ApplResendFlag e.g. are reasonably all conditionaly required on the ApplID being specified.

  7. I do think Field enumerations should be specified in the message tables, they should be in the Data Dictionaryy only unless there are specific limitations related to when a field is used in a particular message.

  8. The Logon message does not seem to include any changes, remove message from document.

  9. ApplID (1180) does not have a field comment in the Data Dictionary section. Maybe there is one in the extension pack introducing the field - if not add one.

Regards

Rikard

4

Rikard,

Thank you for your comments.

We intentionally avoided the concept of an application sequence heartbeat in order to avoid recreating session-like semantics. The Application Message Request allows the last application sequence number to be requested in essense providing the status of the application. The session level heartbeat continues to serve the purpose of letting the parties know that the session is still alive. If initial implementations show a need a heartbeat can be added in a subsequent extension.

“Appl” is the standard FIX abbreviation for Application. You are correct that the fields using this prefix have very distinct functions. Perhaps ApplVerID should be renamed VerApplID.

The ApplSeq fields state “Used only if application sequencing is in effect”. This sounds like a conditional requirement to me. However, I have added a condition remark as you suggest

I think that when introducing a new message with new fields it is helpful to specify the enumerations at the message level.

Your other suggested formatting changes have been taken into account. A new version will be posted shortly.

Matt Simpson

Comments:

  1. Chapter 4.7 mentions ApplFeedID (1180) - but the field is proposedly
    renamed to ApplID (1180) according to revision notes and Message
    tables. Renaming of existing fields rarely occur, is it considered OK
    as the field is introduced in another post-5.0 extension pack?

  2. The third paragraph of 4.7 mentions “Session level should be exempt
    from using these fields …”. Assume the text should read “Session level
    messages should be…” (i.e. add “messages” to sentence).

  3. The last paragraph of chapter 4.7 has a bullet point of “2.
    Request to see the AppLastSeqNum sent from an application”. This
    raises the question of support for “heartbeats” at the application
    level and if there is a need for an “end-of-file” indication per
    application. Relevant especially in cases where multiple feeds
    from a a set of publishers are consolidated into a single one.
    Repeating queries to verify that no new last message is missed
    seems a doubtful design metaphor.

  4. Chapter 6 in the bullet list mentions “ApplFeedID (1180)”, should be
    “ApplID (1180)” if the field is renamed

  5. I still think the use of “Appl” is confusing as ApplVerID (1128) and
    other session level fields including “Appl” refers to an entirely
    different concept than the “Appl” used in this proposal. (I know, I
    don’t have a better proposal)

  6. The rules of the fields in the Standard Header are not complete.
    ApplSeqNo, ApplLastSeqNo and ApplResendFlag e.g. are reasonably all
    conditionaly required on the ApplID being specified.

  7. I do think Field enumerations should be specified in the message
    tables, they should be in the Data Dictionaryy only unless there
    are specific limitations related to when a field is used in a
    particular message.

  8. The Logon message does not seem to include any changes, remove
    message from document.

  9. ApplID (1180) does not have a field comment in the Data Dictionary
    section. Maybe there is one in the extension pack introducing the
    field - if not add one.

Regards

Rikard

5

[ original email was from Henrik Hedlund - henrik.hedlund@omxgroup.com ]
Matt,

Would you consider at least adding a field that flags the last message for a certain ApplID? That would be helpful in reducing the amount of polling which may occur when a certain “feed” goes quiet. It would also help in a business case I’m currently working on where there is a need to group certain reference data or market data messages into a “batch”. Reception of the last message in that batch would trigger actions at the recipient. Application Sequencing would fit well if only I had a end-of-batch flag.

Regards,
Henrik Hedlund

Rikard,

Thank you for your comments.

We intentionally avoided the concept of an application sequence
heartbeat in order to avoid recreating session-like semantics. The
Application Message Request allows the last application sequence number
to be requested in essense providing the status of the application. The
session level heartbeat continues to serve the purpose of letting the
parties know that the session is still alive. If initial implementations
show a need a heartbeat can be added in a subsequent extension.

“Appl” is the standard FIX abbreviation for Application. You are correct
that the fields using this prefix have very distinct functions. Perhaps
ApplVerID should be renamed VerApplID.

The ApplSeq fields state “Used only if application sequencing is in
effect”. This sounds like a conditional requirement to me. However, I
have added a condition remark as you suggest

I think that when introducing a new message with new fields it is
helpful to specify the enumerations at the message level.

Your other suggested formatting changes have been taken into account. A
new version will be posted shortly.

Matt Simpson

Comments:

  1. Chapter 4.7 mentions ApplFeedID (1180) - but the field is
    proposedly renamed to ApplID (1180) according to revision notes and
    Message tables. Renaming of existing fields rarely occur, is it
    considered OK as the field is introduced in another post-5.0
    extension pack?

  2. The third paragraph of 4.7 mentions “Session level should be exempt
    from using these fields …”. Assume the text should read “Session
    level messages should be…” (i.e. add “messages” to sentence).

  3. The last paragraph of chapter 4.7 has a bullet point of “2. Request
    to see the AppLastSeqNum sent from an application”. This raises the
    question of support for “heartbeats” at the application level and
    if there is a need for an “end-of-file” indication per application.
    Relevant especially in cases where multiple feeds from a a set of
    publishers are consolidated into a single one. Repeating queries to
    verify that no new last message is missed seems a doubtful design
    metaphor.

  4. Chapter 6 in the bullet list mentions “ApplFeedID (1180)”, should
    be “ApplID (1180)” if the field is renamed

  5. I still think the use of “Appl” is confusing as ApplVerID (1128)
    and other session level fields including “Appl” refers to an
    entirely different concept than the “Appl” used in this proposal.
    (I know, I don’t have a better proposal)

  6. The rules of the fields in the Standard Header are not complete.
    ApplSeqNo, ApplLastSeqNo and ApplResendFlag e.g. are reasonably all
    conditionaly required on the ApplID being specified.

  7. I do think Field enumerations should be specified in the message
    tables, they should be in the Data Dictionaryy only unless there
    are specific limitations related to when a field is used in a
    particular message.

  8. The Logon message does not seem to include any changes, remove
    message from document.

  9. ApplID (1180) does not have a field comment in the Data Dictionary
    section. Maybe there is one in the extension pack introducing the
    field - if not add one.

Regards

Rikard