I'm trying to gather an information about FIX protocol for FX (Foreign Exchange) trades.
Some old sources mention that FIX protocol got extended with FX related message support:
http://www.fixprotocol.org/discuss/read/1a070ffc
But I can't quite find details online.
Basically, I need to understand:
What message types are to be used. Can I use AI (Allocation Extraction) or should it be FX specific message type?
Currency/Counter Currency pairs are properly coded.
Which fields are to be used for quantities and/or for exchange rate.
What CFI Codes or Security Types should be used.
What value for Security Exchange (if any) needs to be provided.
Link to a documentation would be sufficient and any comments would be greatly appreciated!
FIX is a very fudgy protocol, and the reality is such that two different FX brokers could choose to use very different message and field definitions to do the same things.
If you are designing a client to connect to an existing commercial interface, you should really check with your intended counterparty ASAP. They should have documentation that describes which messages they support, which fields they require, any field customizations, and any "unorthodox" usages of fields.
If you are designing a server system such that multiple parties are connecting to you, then you will have some choices to make. The fudginess of FIX is a double-edge sword for you: you have a lot of freedom to go your own way, but at the same time it's not paint-by-numbers easy to design. You can just make a best-guess usage of the messages that the default specs provide to you, and make sure to document it for your clients. (In this case, you may want to get some specs from existing counterparties just to get examples.)
Regarding your sources saying that "FIX protocol got extended with FX related message support", most likely that's just new fields and messages. Looks like those might be in FIX 4.4 and up.
If you want a good source for surfing FIX messages, use FIXimate. It's invaluable.
Related
The QuickFix website provides data dictionaries for various versions of FIX (note: I am talking about FIX rather than FIXML). I have not seen any mention of such data dictionaries in the FIX specification, so my assumption is that an independent person (perhaps a QuickFix developer) invented them and they became a de facto standard used across multiple FIX implementations. Does anyone know who invented them? I ask because I want to briefly discuss FIX data dictionaries in a book I am writing, and I would like to credit the inventor.
In addition, I have not been able to find a schema (e.g, DTD or XML Schema) for a FIX data dictionary (again, I am talking about FIX rather than FIXML). Do such things exist?
Confirming, it was me.
When I originally created it, there was no structured version of the FIX specification. The spec was distributed as a Microsoft Word document.
Word would allow you to export a document as HTML. So I did that manually, then created a parser for the resulting HTML documents for each version.
Since the Word documents seemed to be edited by hand, they were quite inconsistent, and the parser needed to handle all sorts of edge cases. But eventually it was able to produce usable structured data.
Since then the FIX repository has been released, which is how the QuickFIX xml document is currently generated (though surprisingly, there is still data cleaning that needs to be done before a good QuickFIX document is generated).
I think there are a few reasons that the QuickFIX version of the spec became popular over the FIX repository.
It is a single document for each version of the spec.
It is more human readable. Tags are referenced only in field definitions. Messages are constructed with the relatively more human readable field names.
There is no barriers to download. Originally if I recall correctly the FIX repository was only available to members. I don't think that's still the case, but you do still need to have an account and be logged in to download the repository.
It's served a function for a large user base. Since the spec can be plugged into QuickFIX and used to generate QuickFIX messages, there was a large installed user base that can plug it and connect to your platform more easily. I believe this led to the adoption by other FIX engines to piggy back on this advantage, which I think is great.
There is no schema for the dictionaries.
Oren Miller created QuickFIX. I assume he or someone from his team invented the format: https://en.wikipedia.org/wiki/QuickFIX
Initial commit from Oren Miller which also contains initial version of DataDictionary:
https://github.com/quickfix/quickfix/commit/3b4df170aa518dd92cb05dc7c3bdbc83779516de#diff-bd791d8e47e80c1bbefe35e7a16453eb6e918c2d76bd26c38a139fc7c5ccc3ca
Imagine I have a fully implemented REST API that offers HATEOAS as well.
Let's assume I browse the root and besides the self link two other links (e.g. one for /users and one for /orders) are returned. As far as I have heard, HATEOAS eliminates the need for out-of-band information. How should a client know what users means? Where are the semantics stored?
I know that is kind of a stupid question, but I really would like to know that.
Suppose you've just discovered Twitter and are using it for the very first time. In your Web browser you see a column of paragraphs with a bunch of links spread around the page. You know there's a way to do something with this, but you don't know specifically what actions are available. How do you figure out what they are?
Well, you look at the links and consider what their names mean. Some you recognize right away based on convention: As an experienced Web user, you have a pretty good idea what clicking on the "home", "search" and "sign out" links is meant to accomplish.
But other links have names you don't recognize. What does "retweet" do? What does that little star icon do?
There are basically two ways you, or anyone, will figure this out:
Through experimentation, which is to say, clicking on the links and seeing what happens, then deriving a meaning for each link from the results.
Through some source of out-of-band information, such as the online help, a tutorial found through a Google search or a friend sitting next to you explaining how the site works.
It's the same with REST APIs. (Recall that REST is intended to model the way the Web enables interaction with humans.)
Although in principle computers (or API-client developers) could deduce the semantics of link relations through experimentation, obviously this isn't practical. That leaves
Convention, based on for instance the IANA 's list of standardized link relations and their meanings.
Out-of-band information, such as API documentation.
There is nothing inconsistent in the notion of REST requiring client developers to rely on something beyond the API itself to understand the meaning of link relations. This is standard practice for humans using websites, and humans using websites is what REST models.
What REST accomplishes is removing the need for out-of-band information regarding the mechanics of interacting with the API. Going back to the Twitter example, you probably had to have somebody explain to you at some point what, exactly, the "retweet" link does. But you didn't have to know the specific URL to type in to make the retweet happen, or the ID number of the tweet you wanted to act on, or even the fact that tweets have unique IDs. The Web's design meant all this complexity was taken care of for you once you figured out which link you wanted to click.
And so it is with REST APIs. It's true that in most cases, the computer or programmer will just need to be told what each link relation means. But once they have that information, they can navigate through the entire API without needing to know anything else about the details of how it's all put together.
REST doesn't eliminate the need for out-of-band information. You still have to document your media-types. REST eliminates the need for out-of-band information in the client interaction with the API underlying protocol.
The semantics are documented by the media-type. Your API root is a resource of a media-type, let's say something like application/vnd.mycompany.dashboard.v1+json, and the documentation for that media type would explain that the link relation users leads to a collection of application/vnd.mycompany.user.v1+json related to the currently authenticated user, and orders leads to a collection of application/vnd.mycompany.order.v1+json.
The library analogy works here. When you enter a library after a book, you know how to read a book, you know how to walk to a bookshelf and pick up the book, and you know how to ask the librarian for directions. Each library may have a different layout and bookshelves may be organized differently, but as long as you know what you're looking for and you and the librarian speak the same language, you can find it. However, it's too much to expect the librarian to teach you what a book is.
Dear stack overflowers,
I am not sure if this is the best place for this question, but I figured I'd give it a shot.
I am currently working on an API that will allow consumers to read/write data about users. i.e. name, emails, phoneNumbers, etc. And, as you could guess by the title, I am also storing ims.
Since users may contain multiple im addresses that belong to different services (e.g. skype, google talk, AIM, etc.), there is a type attribute associated with each im address.
I am at the point where I am attempting to validate the user attributes, and when I arrived to ims I was unable to find a formal specification, or normative document that dictates how these should be formatted/validated.
My question is the following:
Is there a general format that im URI's follow?
*note:*I have stumbled upon RFC 3861 that touches on im addresses. But it seems like this isn't a standard. Additionally, there is only one example here that has the following format:
im:fred#example.com
Since emails are effectively unique identifiers, it seems reasonable that they could be represented in this way.
Could anyone shed light on this?
After looking in several sites, I was unable to find a standard that applies to all IM providers. I even looked in some API documentation (Yahoo and Jabber) without any luck. If anyone else finds anything that leads them to think any different, please share the knowledge. But as for right now, it appears I am out of luck...
I have read a lot of discussions here on SO, watched Jon Moore's presentation (which explained a lot, btw) and read over Roy Fielding's blog post on HATEOAS but I still feel a little in the dark when it comes to client design.
API Question
For now, I'm simply returning xhtml with forms/anchors and definition lists to represent the resources. The following snippet details how I lay out forms/anchors/lists.
# anchors
<li class='docs_url/#resourcename'>
<a rel='self' href='resource location'></a>
</li>
# forms
<form action='action_url' method='whatever_method' class='???'></form>
# lists
<dl class='docs_url/#resourcename'>
<dt>property</dt>
<dd>value</dd>
</dl>
My question is mainly for forms. In Jon's talk he documents form types such as (add_location_form) etc. and the required inputs for them. I don't have a lot of resources but I was thinking of abstract form types (add , delete, update, etc) and just note in the documentation that for (add, update) that you must send a valid representation of the target resource and with delete that you must send the identifier.
Question 1: With the notion of HATEOAS, shouldn't we really just make the client "discover" the form (by classing them add,delete,update etc) and just send back all the data we gave them? My real question here (not meant to be a discussion) is does this follow good practice?
Client Question
Following HATEOAS, with our actions on resources being discover-able, how does this effect client code (consumers of the api) and their ui. It sounds great that following these principals that the UI should only display actions that are available but how is that implemented?
My current approach is parsing the response as xml and usin xpath to look for the actions which are known at the time of client development (documented form classes ie. add,delete,update) and display the ui controls if they are available.
Question 2: Am I wrong in my way of discovery? Or is this too much magic as far as the client is concerned ( knowing the form classes )? Wouldn't this assume that the client knows which actions are available for each resource ( which may be fine because it is sort of a reason for creating the client, right? ) and should the mapping of actions (form classes) to resources be documented, or just document the form classes and allow the client (and client developer) to research and discover them?
I know I'm everywhere with this, but any insight is much appreciated. I'll mark answered a response that answers any of these two questions well. Thanks!
No, you're pretty much spot on.
Browsers simply render the HTML payload and rely on the Human to actually interpret, find meaning, and potentially populate the forms appropriately.
Machine clients, so far, tend to do quite badly at the "interpret" part. So, instead developers have to make the decisions in advance and guide the machine client in excruciating detail.
Ideally, a "smart" HATEOS client would have certain facts, and be aware of context so that it could better map those facts to the requirements of the service.
Because that's what we do, right? We see a form "Oh, they want name, address, credit card number". We know not only what "name", "address", and "credit card" number mean, we also can intuit that they mean MY name, or the name of the person on the credit card, or the name of the person being shipped to.
Machines fail pretty handily at the "intuit" part as well. So as a developer, you get to code in the logic of what you think may be necessary to determine the correct facts and how they are placed.
But, back to the ideal client, it would see each form, "know" what the fields wanted, consult its internal list of "facts", and then properly populate the payload for the request and finally make the request.
You can see that a trivial, and obviously brittle, way to do that is to simply map the parameter names to the internal data. When the parameter name is "name", you may hard code that to something like: firstName + " " + lastName. Or you may consider the actual rel to "know" they're talking about shipping, and use: shipTo.firstName + " " + shipTo.lastName.
Over time, ideally you could build up a collection of mappings and such so that if suddenly a payload introduced a new field, and it happened to be a field you already know about, you could fill that in as well "automatically" without change to the client.
But the simply truth is, that while this can be done, it's pretty much not done. The semantics are usually way to vague, you'd have to code in new "intuition" each time for each new payload anyway, so you may as well code to the payload directly and be done with it.
The key thing, though, especially about HATEOS, is that you don't "force" your data on to the server. The server tells you what it wants, especially if they're giving you forms.
So the thought process is not "Oh, if I want a shipping invoice, I see that, right now, they want name, address and order number, and they want it url encoded, and they want it sent to http://example.com/shipping_invoice. so I'll just always send: name + "&" + address + "&" + orderNumber every time to http://example.com/shipping_invoice. Easy!".
Rather what you want to do is "I see they want a name, address, and order number. So what I'll do is for each request, I will read their form. I will check what fields they want each time. If they want name, I will give them name. If they want address, I will give them address. If they want order number, I will give them order number. And if they have any PRE-POPULATED fields (or even "hidden" fields), I will send those back too, and I will send it in the encoding they asked for, assuming I support it, to the URL I got from the action field of the FORM tag.".
You can see in the former case, you're ASSUMING that they want that payload every time. Just like if you were hard coding URLs. Whereas with the second, maybe they decided that the name and address are redundant, so they don't ask for it any more. Maybe they added some nice defaults for new functionality that you may not support yet. Maybe they changed the encoding to multi-part? Or changed the endpoint URL. Who knows.
You can only send what you know when you code the client, right? If they change things, then you can only do what you can do. If they add fields, hopefully they add fields that are not required. But if they break the interface, hey, they break the interface and you get to log an error. Not much you can do there.
But the more that you leverage HATEOS part, the more of it they make available to you so you can be more flexible: forms to fill out, following redirects properly, paying attention to encoding and media types, the more flexible your client becomes.
In the end, most folks simply don't do it in their clients. They hard code the heck out of them because it's simple, and they assume that the back end is not changing rapidly enough to matter, or that any downtime if such change does happen is acceptable until they correct the client. More typically, especially with internal systems, you'll simply get an email from the developers "hey were changing XYZ API, and it's going live on March 1st. Please update your clients and coordinate with the release team during integration testing. kthx".
That's just the reality. That doesn't mean you shouldn't do it, or that you shouldn't make your servers more friendly to smarter clients. Remember a bad client that assumes everything does not invalidate a good REST based system. These systems work just fine with awful clients. wget ftw, eh?
Taken aback to day when I was confronted about the use of validation code used from the Csla framework. It felt like I was reprimanded for not disclosing the use of the framework to the client.
Is this not the same as using libraries such as jQuery etc?
You absolutely should acknowledge what you're using, IMO.
Some clients may have particularly strict legal requirements (whether for legitimate reasons or not - they're the client, it's not up to you to judge their laywers) and detailing any third party software you're using to create a product for them seems only reasonable.
What reason could you have for not wanting to be open with your client?
This depends on the license of the open source code you are using. Many of them require to acknowledge the use in some credits section, others require you to redistribute the source code, etc. You should read the license and act accordingly.
It depends on the project and the kind of client and whatever contracts you had. However, for a typical consultant delivering code to a customer, I would say no it is very strange that you would be reprimanded for not bothering them with details such as the use of CSLA. That's pretty odd.
It is the same, I have a feeling that you would have been reprimanded for using jQuery as well. There are enterprises that frown upon the use of open source for various reasons.
They boil down to
The type of license and what does it force the user to do
The availability of support in some commercial form
The need to 'share-alike' the results
You should know what's your customer/employer's stance on this. If they don't have a stance, then you have to discuss on a case-by-case basis.
I usually tell people I use a lot of open source and, by seeing the response I get I know the path to follow. If they jump and scream at the mention of open source and the lack of support and whatnot, I just tend to ask for budget to buy commercial components or present good cases as to why the open source version of X is better than the commercial alternatives.
It very much depends on the type of project and the type of client. The real problem here is that you were surprised, which indicates non-alignment of expectations. How did the client motivate its interest in Csla specifically?
If your client needs to know or cares about which technology you use, then you should specify everything as part of the project documentation. If the choices are clearly described, then it is easier to have a discussion about them, if required. Documentation also gives you a way to ask (literally) for 'sign-off', if that is the way you work.
From your question it is not clear whether the problem was the choice of framework, or not having informed the customer.
Even on projects with minimal documentation, if the customer owns the code then I always deliver at least a High-level architecture document that includes the names and exact versions of every software component used, along with a brief description of what it is for and why it was selected. This is also the correct place to address any license issues.