Imported from previous forum
[ original email was from Francesc Prats - fprats@meff.com ]
I would like to know if exists an specific tag to indicate the FIX engine version (please, take into account that I don’t mean the FIX version, f.i. 4.3).
No, this does not exist.
Note that in order to support such a concept, you would need to somehow specify the “name” and likely the “source” (i.e. vendor’s name if commercial product) for the “FIX engine version” to have meaning (to be comprehendable).
> I would like to know if exists an specific tag to indicate the FIX engine version (please, take into account that I don’t mean the FIX version, f.i. 4.3).
>
[ original email was from John Prewett - jprewett@lavatrading.com ]
> I would like to know if exists an specific tag to indicate the FIX engine version (please, take into account that I don’t mean the FIX version, f.i. 4.3).
>
As far as I know, there is no field that exists for this purpose, although I think it would be a good idea.
May I humbly propose the following :
Two new optional fields in the Logon message: "FixEngineName" and "FixEngineVersion".
"FixEngineName" should have a string value that contains a unique name identifying the FIX engine.
"FixEngineVersion" should have a string value indicating the version of the FIX engine. The only problem would be if two different FIX engines happen to use the same value for "FixEngineName" - unlikely but possible.
With many engines populating these fields in a Logon message, it could then be easier to handle non-standard FIX variations.
I know that, when I attempt to certify a new connection with another organization, one of my early questions is "which engine & version are you using?". This gives me some insight as to what variations I might expect on the session layer.
Either way, with the fields being optional, it couldn’t hurt.
> > I would like to know if exists an specific tag to indicate the FIX engine version (please, take into account that I don’t mean the FIX version, f.i. 4.3).
> Two new optional fields in the Logon message: “FixEngineName” and “FixEngineVersion”.
Might I suggest instead using a single field, the content of which is a URL that identifies the engine (c.f. Java packages). Benefits: a single field and a global name resolution system that prevents conflicts/duplicates.
Cheers, Dave
> interesting comments. kind of sad in a way, though, since most of them seem to suggest we’re giving up on FIX as a standard and are now trying to better manage a bunch of different interpretations.
>
I agree, however I do believe that it is a little early to throw your hands up in dispair. On the session layer, FIX has come along in leaps and bounds in terms of conformity. The only major issues Apt has had with session levels in the last couple of years has been funky DIY jobs - Euronext in particular leaps to mind. Otherwise, session level testing tends to be pretty straight forward - looking at our support log there have been only two non-Euronext session level queries in the last two years.
Business level - IOIs have reached a certain level of standardisation. Order management still depends alot on end-user OMS capabilities and business practise. It is easy to see just by flicking through 4.3, that there are an awful lot of tags that seem to be there for a very specific market.
> i think there are enough vendors, product versions, inconsistencies within versions, and proprietary implementations that this approach probably won’t accomplish a whole lot.
>
Maybe, but the situation is getting alot better. Most of the established players have pretty stable code bases, certainly in terms of "on the wire" compatability if not the api. The issues tend to be with internal business processes of the companies or OMSes rather than FIX engine issues.
The ongoing shakeout in the engine market, I think will take care of dealing with multiple engine vendors.
> a more comprehensive solution to the problem, maybe:
>
> i’m curious what the community’s appetite would be for a centralized directory of capabilities and implementations. this could be FIX-specific, or could even extend to business-level capabilities. it could be permissioned, if necessary, and accessible via web services so that newer, smarter engines could use the information to define connection interfaces on a trading-partner basis.
>
> companies publish their capabilities. systems access that information to figure out how best to connect. it’s all be dynamic, and nothing gets out of sync. and it’s scalable.
Apt already has something like this where our engine publishes what message types it supports both in and out via SOAP. It always rejected messages as unhandled if the app did not register interest in them - I know of at least one other well-known commercial FIX engine that does the same. Anyway some of this info is published in the principals and engines pages - and updated when the person can be bothered. The issue does not tend to be at that level, it tends to be at the "How do you deal with multiday orders" level which is very difficult to automate and can be quite subtle.
[ original email was from Sam Johnson - sam.johnson@transacttools.net ]
hi danny. last i heard from you, you were trying to replace the FIX session layer with SMTP email.
obviously i don’t know what “issues Apt has had with session levels”. my comments are not speculative. in the past year over 300 companies have run more than 32,000 session-level tests on OpenFIX. these are the FPL-published “certification tests” and more than half of the test-runs failed. we’ve seen most of the engine/application combinations out there, and although services like OpenFIX are helping the industry to standardize i can assure you there is still a lot of inconsistency.
individual engines defining and publishing their own SOAP interface doesn’t help things, it just results in a bunch of incompatible APIs for requesting capability information. directory services (this is what you’re really talking about) must be either centralized or standardized to be effective. distributing the directory information–pushing it out to the individual interfaces–only works if there is a common API, e.g. if we all agreed to adopt a common, open framework like UDDI (see www.uddi.org). We’re big fans of the idea, and TransactTools has been a member of the UDDI Advisory Group for more than a year.
[ original email was from Steve Wilkinson - steve.wilkinson@solutionforge.com ]
Notwithstanding the differing opinions on session level compatibility, I share the view that a directory-based approach is preferable to explicitly exposing details about the underlying products used to implement the FIX session, especially as the majority of the ‘hard’ integration issues are at the business level rather than explicitly at the session level.
At the risk of taking on more work, is there scope here for a working group to look into the application of directory services to this problem? Obviously, whilst this is a genuine issue for the industry, I guess vendors (including us) would need to be convinced there is an opportunity to make money out of it (bottom line), and users would need to be convinced of the value proposition of such solutions.
Others’ thoughts?
Steve.
> hi danny. last i heard from you, you were trying to replace the FIX session layer with SMTP email.
>
> obviously i don’t know what “issues Apt has had with session levels”. my comments are not speculative. in the past year over 300 companies have run more than 32,000 session-level tests on OpenFIX. these are the FPL-published “certification tests” and more than half of the test-runs failed. we’ve seen most of the engine/application combinations out there, and although services like OpenFIX are helping the industry to standardize i can assure you there is still a lot of inconsistency.
>
> individual engines defining and publishing their own SOAP interface doesn’t help things, it just results in a bunch of incompatible APIs for requesting capability information. directory services (this is what you’re really talking about) must be either centralized or standardized to be effective. distributing the directory information–pushing it out to the individual interfaces–only works if there is a common API, e.g. if we all agreed to adopt a common, open framework like UDDI (see www.uddi.org). We’re big fans of the idea, and TransactTools has been a member of the UDDI Advisory Group for more than a year.
>
>
[ original email was from John Prewett - jprewett@lavatrading.com ]
The scope of this thread seems to have widened somewhat…
I still think it can be useful to document the Fix engine & version in the Logon message with optional field(s). This would assist a FIX engine to handle non-standard session-layer issues.
On the subject of a database(directory) of known issues with various counterparts which would include the business message content, I most definitely agree that this would be useful.
Any other position would be at variance with my previous post on this subject (although I reserve the right to be inconsistently inconsistent) :
old discussion entitled "Suggestion: Database of deviations from standards"
http://www.fixprotocol.org/cgi-bin/BBS.cgi?menu=710&board=1&thread=2086#jumpto
While a propagation mechanism for this database is a good subject, I would prefer to focus on the database content and discuss propagation issues later.
Go Sam.
> hi danny. last i heard from you, you were trying to replace the FIX session layer with SMTP email.
>
I thought we had met since summer 1998, there was a guy called Sam Johnson who’s the spitting image of you at SIA this year. Anyway, Apt has since seen the very bright light.
> obviously i don’t know what “issues Apt has had with session levels”. my comments are not speculative. in the past year over 300 companies have run more than 32,000 session-level tests on OpenFIX. these are the FPL-published “certification tests” and more than half of the test-runs failed. we’ve seen most of the engine/application combinations out there, and although services like OpenFIX are helping the industry to standardize i can assure you there is still a lot of inconsistency.
>
Thought it was over 600, anyway… the only change Apt has had to make a change to be able to connect, logon, recover and maintain a FIX session in two years was for Euronext. We have come across things like some companies can only handle to infinity resend requests, which has not required a change. We have people who do not send test requests after logons, some people gap fill in one go, some don’t, some require it to be in one go, most don’t. But none of this causes engines not to communicate, or lose messages.
> individual engines defining and publishing their own SOAP interface doesn’t help things, it just results in a bunch of incompatible APIs for requesting capability information. directory services (this is what you’re really talking about) must be either centralized or standardized to be effective. distributing the directory information–pushing it out to the individual interfaces–only works if there is a common API, e.g. if we all agreed to adopt a common, open framework like UDDI (see www.uddi.org). We’re big fans of the idea, and TransactTools has been a member of the UDDI Advisory Group for more than a year.
>
>
You misunderstood what I said. We give a list of message types that a connection accepts or sends and have an option to reject those not handled by the app - as I believe do a couple of other vendors.
Most of the issues that we come across are long the lines of:
My broker does not accept GTC, so I pretend to do it by sending orders, getting them cancelled at the end of the day and send a new one the following day to pretend that it is actually the same order. How do I tie the orders up. If I want to move globally from just Europe, what constitutes end of day.
or:
One company sends list orders as new orders with an ID that ties them all up and another company actually uses the list orders in 4.2.
I would honestly love to see how UDDI can in a programatic and automated way solve this. I can see how simulation and test tools can help, I can see how brokers and fund managers insisting on doing it the standard way - if we can all agree - can help. If you can do it then I see a number of ways of making money - less time for integration, lower support costs, and possibly a subscription based model - I just do not see how you can eliminate the above probs. But then, Sam, you were always way smarter than me.
Cheers