Well, Actually Initial discussion was not done with the participation of
ESB team, above ideas are came-up
based on the call that we (me and suho) had with Asanka few months back...

But I had an offline chat with Kasun.I regarding this, and He also felt it
is better to move FIX transport
as a separate carbon component but we have not done a proper discussion or
plan regarding how this needs to be
proceed and how is this supposed to be used by ESB..

Regards,
Mohan



On Thu, Jul 18, 2013 at 6:55 PM, Samisa Abeysinghe <[email protected]> wrote:

> Well, I was asking, if we move, then how is this supposed to be used by
> ESB?
>
>
> On Thu, Jul 18, 2013 at 10:10 AM, Mohanadarshan Vivekanandalingam <
> [email protected]> wrote:
>
>> Move is not started yet... It is in the discussion level... We need to
>> find the best way to do that because we
>> need to get the participation of ESB team and some others for this...
>>
>> Regards,
>> Mohan
>>
>> On Thu, Jul 18, 2013 at 5:40 AM, Samisa Abeysinghe <[email protected]>wrote:
>>
>>> When the move is done, who is it supposed to be used by ESB?
>>>
>>>
>>> On Wed, Jul 17, 2013 at 9:09 PM, Mohanadarshan Vivekanandalingam <
>>> [email protected]> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Thanks,
>>> Samisa...
>>>
>>> Samisa Abeysinghe
>>> VP Engineering
>>> WSO2 Inc.
>>> http://wso2.com
>>> http://wso2.org
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *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
>>
>>
>
>
> --
>
> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*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

Reply via email to