Imported from previous forum
I read throught the Fixml implementation guide. It is not clear how the message should be transported. It seems that fixprotocol.org doesn’t want to narrow down the options. I read some propose to use MQ series. I have yet to see whether any one is interested in using web service as a FIXML transport. I see someone propose to use existing FIX to carry FIXML, using specific field to indicate that this is FIXML, not FIX. I can understand it is to preseve the existing investment. However, we can grow some hybrid animal that the rest of the XML world couldn’t recognize.
[ original email was from Ian Orford - ian.orford@ubs.com ]
> I read throught the Fixml implementation guide. It is not clear how the
message should be transported. It seems that fixprotocol.org doesn’t
want to narrow down the options. I read some propose to use MQ series. I
have yet to see whether any one is interested in using web service as a
FIXML transport. I see someone propose to use existing FIX to carry
FIXML, using specific field to indicate that this is FIXML, not FIX. I
can understand it is to preseve the existing investment. However, we can
grow some hybrid animal that the rest of the XML world couldn’t
recognize.
I’m not sure WebServices naturally lends itself to FIX message flow. It’s a request/response protocol which doesnt fit in with most FIX message flow.
I guess one solution would be for both sides to setup a WebServer. The request becomes the message and the response becomes the acknowledgement.
[ original email was from Charles Ballance - c.ballance@verizon.net ]
> > I read throught the Fixml implementation guide. It is not clear how
the message should be transported. It seems that fixprotocol.org
doesn’t want to narrow down the options. I read some propose to use MQ
series. I have yet to see whether any one is interested in using web
service as a FIXML transport. I see someone propose to use existing
FIX to carry FIXML, using specific field to indicate that this is
FIXML, not FIX. I can understand it is to preseve the existing
investment. However, we can grow some hybrid animal that the rest of
the XML world couldn’t recognize.I’m not sure WebServices naturally lends itself to FIX message flow.
It’s a request/response protocol which doesnt fit in with most FIX
message flow.I guess one solution would be for both sides to setup a WebServer. The
request becomes the message and the response becomes the
acknowledgement.
Web Services implementation would introduce too much overhead. Even if
the underlying transport were not HTTP/S(which would have headers), you
still need to deal with the SOAP envelope. This would probably double
the size of the message as well as require processing. I don’t see
this as a viable option.
I read throught the Fixml implementation guide. It is not clear how
the message should be transported. It seems that fixprotocol.org
doesn’t want to narrow down the options. I read some propose to use
MQ series. I have yet to see whether any one is interested in using
web service as a FIXML transport. I see someone propose to use
existing FIX to carry FIXML, using specific field to indicate that
this is FIXML, not FIX. I can understand it is to preseve the
existing investment. However, we can grow some hybrid animal that
the rest of the XML world couldn’t recognize.I’m not sure WebServices naturally lends itself to FIX message flow.
It’s a request/response protocol which doesnt fit in with most FIX
message flow.I guess one solution would be for both sides to setup a WebServer. The
request becomes the message and the response becomes the
acknowledgement.
Web Services implementation would introduce too much overhead. Even if
the underlying transport were not HTTP/S(which would have headers), you
still need to deal with the SOAP envelope. This would probably double
the size of the message as well as require processing. I don’t see this
as a viable option.
Compared with FIX, FIXML introduces a lot of overhead. However, it
introduces self-describing, structured data capable of expressing complex data relationship and data model. Overhead has two implications, data processing power and network bandwidth. In today’s application of FIX protocol, what is a typical volumne and performance requirements for FIX products?