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: [email protected]
phone:(+94) 771117673
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
