[This message was posted by Andy Faibishenko of Lasalle Technology <a...@lasalletech.com> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/0b99dd58 - PLEASE DO NOT REPLY BY MAIL.]
> Andy, > > No problem - I appreciate the extra information as this is what I am > looking for....some more color on QuickFix and whether it's a viable > solution or whether we need to introduce some vendor tools as well into > the mix. As I mentioned we are a .NET shop here at Fiserv for better or > for worse. I came from BofA where we were not using .NET. I'm also > trying to find out how difficult it would be to access QuickFix/J from > .NET. Thanks again for your post. It all depends on what your architecture looks like. If you can deal with QuickFIX/J running in a separate process and communicating with your .NET apps through some type of IPC mechanism then it is fairly straightforward. If you want to have them live in the same process space, you basically have to use JNI to call Java (I think there are some third party products that can make this process easier through code generation). That approach is a lot less straightforward and robust... [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to FIX-Protocol@googlegroups.com To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
