You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Asanka Abeysinghe <as...@hotmail.com> on 2008/06/23 09:18:06 UTC
Enabling Synapse to communicate with deferent FIX versions
Hi,
I am working on synapse-1.2 to configure a proxy service to bridge two FIX endpoints with different versions. E.g. FIX.4.0 and FIX.4.1 (only compatible messages between two versions).
Current Synapse FIX implementation got a stopper for the above requirement because it validates the incoming message version and the outgoing message version defined in the FIX message header (BeginString/Tag 10).
Validations done inside the class org.apache.synapse.transport.fix.FIXTransportSender.
Quickfix/j (FIX engine used in Synapse) will be doing the FIX message validations based on the session configuration and the FIX-specification, so it is not required to do FIX validations inside the Synapse transport layer.
A synapse user can make messages compatible by defining proper message definitions/ FIX-specs.
Asanka A.
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Enabling Synapse to communicate with deferent FIX versions
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi,
It seems I have made a small mistake in my previous mail. I should have said
thanks 'Asanka' instead of thanks 'Asankha'. :-)
Thanks
Best Regards,
Hiranya Jayathilaka
On Tue, Jun 24, 2008 at 3:21 PM, Hiranya Jayathilaka <hi...@gmail.com>
wrote:
> Hi,
>
> Thanks Asankha for the input.
>
> We included this validation feature in the FIXTransportSender intentionally
> because we were not very happy with the level of validation offered by
> Quickfix/J. Also these restrictions imposed by the transport can help in
> sending response messages when a service is having multiple sessions on the
> acceptor side.
>
> Anyway what you say also makes perfect sense. Therefore we can consider
> removing the validation feature from the FIXTransportSender or may be we can
> consider having that as an optional feature. I have already done this in my
> local working copy of Synapse. Therefore please raise a JIRA regarding this
> improvement. Then we can start working on it.
>
> Thanks again for your feedback and keep them coming. We need contributions
> from our users and developers to make the FIX transport a more productive
> and useful piece of software.
>
> Thanks
>
> Best Regards,
> Hiranya Jayathilaka
>
> We need feedback from our users and developers to make the FIX transport a
> more productive and useful piece of software.
>
>
>
>
> On Mon, Jun 23, 2008 at 12:48 PM, Asanka Abeysinghe <as...@hotmail.com>
> wrote:
>
>>
>> Hi,
>> I am working on synapse-1.2 to configure a proxy service to bridge two FIX
>> endpoints with different versions. E.g. FIX.4.0 and FIX.4.1 (only compatible
>> messages between two versions).
>>
>> Current Synapse FIX implementation got a stopper for the above requirement
>> because it validates the incoming message version and the outgoing message
>> version defined in the FIX message header (BeginString/Tag 10).
>>
>> Validations done inside the class
>> org.apache.synapse.transport.fix.FIXTransportSender.
>>
>> Quickfix/j (FIX engine used in Synapse) will be doing the FIX message
>> validations based on the session configuration and the FIX-specification, so
>> it is not required to do FIX validations inside the Synapse transport layer.
>>
>> A synapse user can make messages compatible by defining proper message
>> definitions/ FIX-specs.
>>
>> Asanka A.
>> _________________________________________________________________
>> News, entertainment and everything you care about at Live.com. Get it now!
>> http://www.live.com/getstarted.aspx
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
Re: Enabling Synapse to communicate with deferent FIX versions
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Tue, Jun 24, 2008 at 5:51 PM, Asanka Abeysinghe <as...@wso2.com> wrote:
> Multiple session with different FIX version using same sender-comp-id(Tag
> 49) and sender-sub-id(Tag 50) is a very rare case. FIX users make it deffer
> to identify the message created place / desk/ trader, so we are on safe
> side. And we have an additional field call senderlocation id (Tag 142) for
> additional information. Drawback will be to read the tags need to process
> the message payload.
Exactly. And as long as the FIX applications communicating via Synapse use
DeliverTo* and OnBehalf* fields we should be fine. Synapse already is
capable of performing the routing based on the values of these fields as
specified in the FIX specs.
Thanks
Best Regards,
Hiranya Jayathilaka
> Asanka A.
> Hiranya Jayathilaka wrote:
>
>>
>> No. When there are multiple FIX sessions of different versions connected
>> to the same acceptor, Synapse will have no way of determining how to forward
>> the response messages if DeliverToX fields are not in use. So the
>> restrictions imposed by the validation prevent the user from doing something
>> like that. Anyway as you said, being able to bridge FIX sessions with
>> different versions is a great usecase and the above scenario is a very
>> special case. So in this case we can afford to remove validation or make it
>> an optional feature.
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> <ma...@synapse.apache.org>
>> For additional commands, e-mail: dev-help@synapse.apache.org
>> <ma...@synapse.apache.org>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
Re: Enabling Synapse to communicate with deferent FIX versions
Posted by Asanka Abeysinghe <as...@wso2.com>.
Multiple session with different FIX version using same
sender-comp-id(Tag 49) and sender-sub-id(Tag 50) is a very rare case.
FIX users make it deffer to identify the message created place / desk/
trader, so we are on safe side. And we have an additional field call
senderlocation id (Tag 142) for additional information. Drawback will
be to read the tags need to process the message payload.
Asanka A.
Hiranya Jayathilaka wrote:
>
> No. When there are multiple FIX sessions of different versions
> connected to the same acceptor, Synapse will have no way of
> determining how to forward the response messages if DeliverToX fields
> are not in use. So the restrictions imposed by the validation prevent
> the user from doing something like that. Anyway as you said, being
> able to bridge FIX sessions with different versions is a great usecase
> and the above scenario is a very special case. So in this case we can
> afford to remove validation or make it an optional feature.
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> <ma...@synapse.apache.org>
> For additional commands, e-mail: dev-help@synapse.apache.org
> <ma...@synapse.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Enabling Synapse to communicate with deferent FIX versions
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi,
On Tue, Jun 24, 2008 at 4:59 PM, Asanka Abeysinghe <as...@wso2.com> wrote:
> Hi Hiranya,
> Jira issue is created.
> Quickfix got a reasonable FIX session + message level validation that even
> use in production systems. Level of the validations will be based on the
> accuracy of the specification used by the user. If more validations required
> user can plug ruby/python scripts to the QF engine.
> Is Synapse using the BeginString to identify the correct endpoint to send
> the responses back (I don't think so ) ?
No. When there are multiple FIX sessions of different versions connected to
the same acceptor, Synapse will have no way of determining how to forward
the response messages if DeliverToX fields are not in use. So the
restrictions imposed by the validation prevent the user from doing something
like that. Anyway as you said, being able to bridge FIX sessions with
different versions is a great usecase and the above scenario is a very
special case. So in this case we can afford to remove validation or make it
an optional feature.
Thanks
Best Regards,
Hiranya Jayathilaka
>
> FIX 4.1 to 4.2 specifications got lot of incompatibility issues other
> than that most of the versions are compatible so this feature will be
> useful for a FIX user.
> Cheers
> Asanka A.
>
> Hiranya Jayathilaka wrote:
>
>> Hi,
>>
>> Thanks Asankha for the input.
>>
>> We included this validation feature in the FIXTransportSender
>> intentionally because we were not very happy with the level of validation
>> offered by Quickfix/J. Also these restrictions imposed by the transport can
>> help in sending response messages when a service is having multiple sessions
>> on the acceptor side.
>>
>> Anyway what you say also makes perfect sense. Therefore we can consider
>> removing the validation feature from the FIXTransportSender or may be we can
>> consider having that as an optional feature. I have already done this in my
>> local working copy of Synapse. Therefore please raise a JIRA regarding this
>> improvement. Then we can start working on it.
>>
>> Thanks again for your feedback and keep them coming. We need contributions
>> from our users and developers to make the FIX transport a more productive
>> and useful piece of software.
>>
>> Thanks
>>
>> Best Regards,
>> Hiranya Jayathilaka
>>
>> We need feedback from our users and developers to make the FIX transport a
>> more productive and useful piece of software.
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
Re: Enabling Synapse to communicate with deferent FIX versions
Posted by Asanka Abeysinghe <as...@wso2.com>.
Hi Hiranya,
Jira issue is created.
Quickfix got a reasonable FIX session + message level validation that
even use in production systems. Level of the validations will be based
on the accuracy of the specification used by the user. If more
validations required user can plug ruby/python scripts to the QF engine.
Is Synapse using the BeginString to identify the correct endpoint to
send the responses back (I don't think so ) ?
FIX 4.1 to 4.2 specifications got lot of incompatibility issues
other than that most of the versions are compatible so this
feature will be useful for a FIX user.
Cheers
Asanka A.
Hiranya Jayathilaka wrote:
> Hi,
>
> Thanks Asankha for the input.
>
> We included this validation feature in the FIXTransportSender
> intentionally because we were not very happy with the level of
> validation offered by Quickfix/J. Also these restrictions imposed by
> the transport can help in sending response messages when a service is
> having multiple sessions on the acceptor side.
>
> Anyway what you say also makes perfect sense. Therefore we can
> consider removing the validation feature from the FIXTransportSender
> or may be we can consider having that as an optional feature. I have
> already done this in my local working copy of Synapse. Therefore
> please raise a JIRA regarding this improvement. Then we can start
> working on it.
>
> Thanks again for your feedback and keep them coming. We need
> contributions from our users and developers to make the FIX transport
> a more productive and useful piece of software.
>
> Thanks
>
> Best Regards,
> Hiranya Jayathilaka
>
> We need feedback from our users and developers to make the FIX
> transport a more productive and useful piece of software.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Enabling Synapse to communicate with deferent FIX versions
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi,
Thanks Asankha for the input.
We included this validation feature in the FIXTransportSender intentionally
because we were not very happy with the level of validation offered by
Quickfix/J. Also these restrictions imposed by the transport can help in
sending response messages when a service is having multiple sessions on the
acceptor side.
Anyway what you say also makes perfect sense. Therefore we can consider
removing the validation feature from the FIXTransportSender or may be we can
consider having that as an optional feature. I have already done this in my
local working copy of Synapse. Therefore please raise a JIRA regarding this
improvement. Then we can start working on it.
Thanks again for your feedback and keep them coming. We need contributions
from our users and developers to make the FIX transport a more productive
and useful piece of software.
Thanks
Best Regards,
Hiranya Jayathilaka
We need feedback from our users and developers to make the FIX transport a
more productive and useful piece of software.
On Mon, Jun 23, 2008 at 12:48 PM, Asanka Abeysinghe <as...@hotmail.com>
wrote:
>
> Hi,
> I am working on synapse-1.2 to configure a proxy service to bridge two FIX
> endpoints with different versions. E.g. FIX.4.0 and FIX.4.1 (only compatible
> messages between two versions).
>
> Current Synapse FIX implementation got a stopper for the above requirement
> because it validates the incoming message version and the outgoing message
> version defined in the FIX message header (BeginString/Tag 10).
>
> Validations done inside the class
> org.apache.synapse.transport.fix.FIXTransportSender.
>
> Quickfix/j (FIX engine used in Synapse) will be doing the FIX message
> validations based on the session configuration and the FIX-specification, so
> it is not required to do FIX validations inside the Synapse transport layer.
>
> A synapse user can make messages compatible by defining proper message
> definitions/ FIX-specs.
>
> Asanka A.
> _________________________________________________________________
> News, entertainment and everything you care about at Live.com. Get it now!
> http://www.live.com/getstarted.aspx
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>