At the moment there are two types of implementations available for FIX transport.
1) FIX transport which is in the synapse level that used by ESB 2) Basic FIX transport broker(not released) implementation in CEP But based on the discussion that we made few months ago, It is not good to have two separate implementations for FIX transport. But It is not possible to use Synapse level FIX transport by CEP because of some limitations. Since it is better to move out the FIX transport from Synapse and allow to use by any products. Please refer the architecture mail Thread "FIX Broker for CEP" for more information. Please find some notes that we came-up from the discussion that we had before. * Current ESB FIX Transport* - It is designed in the synapse level. - When ESB receives a FIX message it removes the header and trailer and converts it into xml. Because of this implementation it can handle multiple FIX message versions easily. - ESB uses only one FIX instance to receive and send FIX messages. - Currently its converting the Fix message to XML (here we are not using the stranded XML format ) provided by quickfix) in the transport itself and sending it as a Synapse message - Current implementation only supports 500 TPS. * Current CEP FIX Transport* - Here there will be two parts. To receive the events and to publish the events. - We are receiving the FIX events, convert that into the map and pass in to the Siddhi. - Events that received from siddhi is convert into a FIX message type which is defined by the user using the java reflection. - We handle only one port (can have many sessions) to create multiple sessions *Ideas that came up * - We need to have single implementation for a specific Transport (one FIX transport for both ESB, CEP and etc...) - Moving FIX implementation from synapse to Axis2 - In common scenario mostly people use custom message tags. - Need to develop specific formatter builder to create xml/Map. - Map the Fix message header values as Soap headers when converting to XML, this will allow ESB to route the messages more efficiently. Ideas are welcomed on this... WDYT? Reagrds, Mohan -- *V. Mohanadarshan* *Software Engineer,* *Data Technologies Team,* *WSO2, Inc. http://wso2.com * *lean.enterprise.middleware.* * * email: mo...@wso2.com phone:(+94) 771117673
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture