Imported from previous forum
We spent several weeks and we had many meetings on what is Application level and session level and how to divide it up and could not reach a satisfactory conclusion (this occurred during the FIX5.0 Usage Subcommittee meetings). Instead we needed a different approach or concept if you will. The concept here is that an API needs to present the StandardHeader from the session level in its entirety to the application. And further, the API needs to map the session level header backward to FIX.4.x headers if FIX.4.x is the application level. This is clearly stated in the FIXT specification. There is a clear separation - the StandardHeader, StandardTrailer, and Session Level messages belong to the Session. Now what complications arise? Some of the content of fields in the Session Layer are coupled to and dependent upon those versions. So how do we resolve this dilemma? The way to resolve this dilemma is to define a binding protocol that specifies unambiguously how the application level messages are bound to the session level. Certain values for fields such as ApplVerID, MsgType for instance are either fully defined or extended by the Application level. For instance the MsgType(tag 35) field for FIXT.1.1 should contain only: 0 Heartbeat 1 TestRequest 2 ResendRequest 3 Reject 4 SequenceReset 5 Logout A Logon n XML_non_FIX So the MsgType field should be specified within the FIXT repository as being extendable by the Application Layer. The ApplVerID field on the other hand has no meaning to FIXT- bottom line is FIXT could care less how this field is used. 0 = FIX27 1 = FIX30 2 = FIX40 3 = FIX41 4 = FIX42 5 = FIX43 6 = FIX44 7 = FIX50 8 = FIX50SP1 9 = FIX50SP2 So the ApplVerID should be specified within the FIXT repository as requiring definition by the Application Layer. The Text(58) is used independently by the majority of application messages so the Text(58) should be identified as a field shareable (or Shared) across layers. (Long term we should uncouple this and have ApplicationLevel fields – we have started this process by having a RejectText separate from a general purpose text field. But Shirley I am digressing.) Likewise, RefMsgType(372) is shareable between the FIX session and application level – it should be identified as Shared. But go a step further, not only does RefMsgType have to be shareable it has to be extendable – just like RefMsgType(372). RefSeqNum(45) also falls into this category as well. (Another digression – I think that the coupling of BusinessMessageReject to the session was ill advised at the time – even before separation – I can tell you that the reliance on the session level identification has created issues for us in building systems when you have multiple gateways between the sender and recipient of the message. But Shirley I am digressing yet again. And I apologize for calling you all Shirley.) So Phil and I came up independently with the same resolution – extend the FIXT Session repository to codify the rules for the sharing of fields between Session and Application level and this is my first proposed implementation to be shot down in a hail of alternative ideas: ApplicationLevelVisibility { NotVisible==0; // Not visible to the Application level Visible==1; // Visible to application - majority or maybe all // StandardHeader fields are visible Shared==2; // takes care of Text(58), RefSeqNum(45) Extendable==4; // takes care of MsgType(35), RefMsgType(372) Definable==8; // takes care of ApplVerID(1128), DefaultApplVerID } Why create a bit map you ask? Because there is a certain independence to these attributes. We might also consider as a separation of concepts here and have a Visibility attribute and a Mutability attribute - come to think of it I like this better. I think we could go a step further with AppVerID and say that values 0 through 1023 are reserve for FIX Protocol versions and values 1024 and greater are available for non-FIX protocol versioning. This would be quite useful when creating application bindings for things such as FpML, ISO 20022, XBRL for instance.
Following up the last thread:
Mutability could have {
Immutable = 0
Extendable = 1
Definable = 2
}
Visibility could have {
Not Visible=0
Visible=1
}
Error in first post:
Likewise, RefMsgType(372) is shareable between the FIX session and application level – it should be identified as Shared. But go a step further, not only does RefMsgType have to be shareable it has to be extendable – just like RefMsgType(372).
Should read:
Likewise, RefMsgType(372) is shareable between the FIX session and application level – it should be identified as Shared. But go a step further, not only does RefMsgType have to be shareable it has to be extendable – just like MsgType(35).
Further work on this today with Phil actually has extended the concept to address the issue of not having a StandardHeader or StandardTrailer defined within the Application Layer.
The concept extends the field level concept in creating empty StandardHeader and Trailers in the Application Layer which will be replaced with the StandardHeader and StandardTrailer of the Transport.
The concept here would be to take the union of the Application StandardHeader and the Session Level StandardHeader to create a bound instance of Session+Application.
A trivial thing to do then is to have all the standard bound instances generated statically as part of the repository. For instance, provide versions of:
FIXT.1.1+FIX.4.0
FIXT.1.1+FIX.4.1
…
FIXT.1.1+FIX.5.0
FIXT.1.1+FIX.5.0SP1
FIXT.1.1+FIX.5.0SP2
The XSLT and XQuery static binding code would be included in the repository distribution and serve as a reference implementation.
This actually seems to address the identified issues so far.
We spent several weeks and we had many meetings on what is Application
level and session level and how to divide it up and could not reach a
satisfactory conclusion (this occurred during the FIX5.0 Usage
Subcommittee meetings). Instead we needed a different approach or
concept if you will.The concept here is that an API needs to present the StandardHeader from
the session level in its entirety to the application. And further, the
API needs to map the session level header backward to FIX.4.x headers if
FIX.4.x is the application level. This is clearly stated in the FIXT
specification.There is a clear separation - the StandardHeader, StandardTrailer, and
Session Level messages belong to the Session.Now what complications arise?
Some of the content of fields in the Session Layer are coupled to and
dependent upon those versions.So how do we resolve this dilemma?
The way to resolve this dilemma is to define a binding protocol that
specifies unambiguously how the application level messages are bound to
the session level.Certain values for fields such as ApplVerID, MsgType for instance are
either fully defined or extended by the Application level.For instance the MsgType(tag 35) field for FIXT.1.1 should contain only:
Heartbeat 1 TestRequest 2 ResendRequest 3 Reject 4 SequenceReset 5
Logout A Logon n XML_non_FIXSo the MsgType field should be specified within the FIXT repository as
being extendable by the Application Layer.The ApplVerID field on the other hand has no meaning to FIXT- bottom
line is FIXT could care less how this field is used.= FIX27 1 = FIX30 2 = FIX40 3 = FIX41 4 = FIX42 5 = FIX43 6 = FIX44 7 = FIX50 8 = FIX50SP1 9 = FIX50SP2So the ApplVerID should be specified within the FIXT repository as
requiring definition by the Application Layer.The Text(58) is used independently by the majority of application
messages so the Text(58) should be identified as a field shareable (or
Shared) across layers. (Long term we should uncouple this and have
ApplicationLevel fields – we have started this process by having a
RejectText separate from a general purpose text field. But Shirley I am
digressing.)Likewise, RefMsgType(372) is shareable between the FIX session and
application level – it should be identified as Shared. But go a step
further, not only does RefMsgType have to be shareable it has to be
extendable – just like RefMsgType(372).RefSeqNum(45) also falls into this category as well.
(Another digression – I think that the coupling of BusinessMessageReject
to the session was ill advised at the time – even before separation – I
can tell you that the reliance on the session level identification has
created issues for us in building systems when you have multiple
gateways between the sender and recipient of the message. But Shirley I
am digressing yet again. And I apologize for calling you all Shirley.)So Phil and I came up independently with the same resolution – extend
the FIXT Session repository to codify the rules for the sharing of
fields between Session and Application level and this is my first
proposed implementation to be shot down in a hail of alternative ideas:ApplicationLevelVisibility { NotVisible==0; // Not visible to the
Application level Visible==1; // Visible to application - majority or
maybe all // StandardHeader fields are visible Shared==2; // takes care
of Text(58), RefSeqNum(45) Extendable==4; // takes care of MsgType(35),
RefMsgType(372) Definable==8; // takes care of ApplVerID(1128),
DefaultApplVerID }Why create a bit map you ask?
Because there is a certain independence to these attributes. We might
also consider as a separation of concepts here and have a Visibility
attribute and a Mutability attribute - come to think of it I like
this better.I think we could go a step further with AppVerID and say that values 0
through 1023 are reserve for FIX Protocol versions and values 1024 and
greater are available for non-FIX protocol versioning. This would be
quite useful when creating application bindings for things such as FpML,
ISO 20022, XBRL for instance.