+1
I'm just about to ask the question "Is it a must to convert the FIX
payload to XML ?" :-)
Map will be an ideal data structure to store FIX, because FIX construct
with name value pairs.
So we can stick with the current structure till the map message based
implementation comes up, the feedback got from Ruwan and Hiranya did
remove the concerns I had (Thanks folks).
Asanka A.
Paul Fremantle wrote:
I think the correct model to hold the fix data in would be a Map
message, since this is the closest mirror in Java/Synapse to the
native FIX model.
We already discussed doing an efficient implementation of Map inside
Axiom, that only translates the Map into XML if required.
Then we could do the following:
1) provide a XPath fn that can look at Map, so you can do CBR without
needing to convert to XML
2) provide a mediator that transforms into the QFJ XML format (if
anyone uses this?)
3) provide a mediator that transforms into the official FIXML XML syntax
4) the Map would auto-translate into a synapse Map XML format if
anyone tried to access it as XML.
This way we could do routing from FIX to FIX with minimal
transformation. In fact, we could make the QFJ message object
implement the Map interface and then there would be zero
transformation/conversion for FIX->FIX routing, but you could still do
XPath expression content based routing on FIX parameters.
This all pre-supposes we can write an OMDataSource OMElement based on a Map.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
