Imported from previous forum
Hi,
I am wondering what is a decent way to spawn a FIX (buy/sell) request from a JSP to a FIX engine written in java. One person mentioned a request may go to an OMS first which might then spawn the FIX request. I am trying to set up a proof-of-concept test and could mock up an OMS but i still have the same basic inter process communication issue, ie. calling a proceedure running on one jvm (the FIX engine) from an application running on another (the JSP). RMI, sockets, pipes, soap, but what is a decent/realistic/practical choice? Thanks in advance!
Hi,
I dont think there is one best way, but we always used sockets or msmq(with jintegra).
Regards
Byron
Net2s
Hi,
I am wondering what is a decent way to spawn a FIX (buy/sell) request
from a JSP to a FIX engine written in java. One person mentioned a
request may go to an OMS first which might then spawn the FIX request. I
am trying to set up a proof-of-concept test and could mock up an OMS but
i still have the same basic inter process communication issue, ie.
calling a proceedure running on one jvm (the FIX engine) from an
application running on another (the JSP). RMI, sockets, pipes, soap, but
what is a decent/realistic/practical choice? Thanks in advance!
[ original email was from Himanshu Sharma - hsharma@knighttrading.com ]
> Hi,
I am wondering what is a decent way to spawn a FIX (buy/sell) request
from a JSP to a FIX engine written in java. One person mentioned a
request may go to an OMS first which might then spawn the FIX request. I
am trying to set up a proof-of-concept test and could mock up an OMS but
i still have the same basic inter process communication issue, ie.
calling a proceedure running on one jvm (the FIX engine) from an
application running on another (the JSP). RMI, sockets, pipes, soap, but
what is a decent/realistic/practical choice? Thanks in advance!
IMHO, the solutions can be :
com1 com2
JSP <-------------> FIX Engine FE1<-----------------> FIX Engine FE2
I guess JSP is the UI.
com1 is the communication layer between UI and your FE1 (gateway to the world). and FE2 is the destination FIX engine.
com1 depends on the API provided by FE1:
- can be tcp
- messaging (like TIBRV, java msg queue, etc. ) or
- in-process communication (JSP directly calls some method in FE1 to send/receive ord/exec) where FE1 is an instance within same JVM as JSP.
com2 is mostly tcp.
For proof of concept, you can work on option 3 and write a basic FE1 layer yourself to connect to FE2 and send/receive admin and applications messages.
HTH