Hi,
That's a real beginner question, but I've seen the docs these last days, and these 2 possibilities to communicate with Forex https://www.dukascopy.com/swiss/english ... forex_api/ or https://www.dukascopy.com/swiss/english ... i/fix_api/

JForex looks really fine, as there are much things done by yourselves, in the strategies etc..
but our small company probably need FIX API for maybe making a more real-time event system, also something independant of the broker

Is there a way to reuse the JForexAPI but based on the FIX communications?

thanks

You can accomplish extremely sophisticated, and fast order control with the JForex API.

If you are sophisticated, you will use it in "standalone" mode. But it will need to be a Java subsystem, since it is an Java API. The Java subsystem could interface to some existing system you have but, again, if you use FIX you'll want to stay with FIX.

Unless you already use FIX, don't even consider using FIX. But if you're sophisticated using FIX, you'll understand how FIX works, and get in touch with the FIX people at Dukascopy.

FIX systems require considerable testing and usually certification. JForex API has no such restrictions.

HyperScalper

FIX is not so complicate to use, there are many libs, and isn't JForex only working for dukascopy's server? or what exactly did you mean with "The Java subsystem could interface to some existing system"?, I've not used enough JForexSDK yet though, but ideally it would be good to not be too dependant on dukascopy's software.

without this limitation, I'd really want to do all that in that java api

Why don't you give us an idea what you're planning to do?

What are the operational requirements for your system, and what "strategy" would you use to trade?

I am a Micro Scalper, using the JForex API with specialized software. It works just fine for that purpose, dozens of order operations per minute; but my approach is for small traders, not "institutional strength" trading

HyperScalper

The same case as you I think, and since this morning I decided to go with JF, all fine.
I don't think there's a good reason to aggregate several brokers for example dukascopy, with Oanda etc.. , but rather choose one (the best)

thanks for helping me, clarifying all that

There's no question that with Dukascopy you have chosen "the best".

Now, it's a question of leveraging their technology. If you're scalping, I could help you with a few things. If your more of a "momentum trend" type of trader, that's a bit different.

As a scalper, you should definitely consider PLACE_BID and PLACE_OFFER order types, and you'll inevitably want to do some MERGING of smaller fills, etc. Personally, I pre-load an order and then "bump" it to the desired price in some instances, etc.

Also, I'd suggest that if you have anything remotely complex, that you do it as a standalone process so that you have much more control over threading, etc. You'll have to handle the Captcha login, etc., but there are examples of how a standalone client works in this forum.

You'll probably want to give yourself a Swing user interface, and get all the "teething problems" related to standalone clients, out of the way, first of all. Then once you have that framework, the "sky's the limit" as to what you can accomplish with the right skills.

You'll want to STRICTLY observe the following rule: IContext.executeTask(Callable) must be used for ALL order operations. If you're in an IStrategy callback context you're already on the right thread, so no worries. (If you're on the Strategy callback thread and you use IContext.executeTask(Callable), and you wait for your Future result, you WILL DEADLOCK. Remember, you're already on the single-threaded callback queue's thread in that case.)

For your Swing user interface (recommended) then you have to observe Swing rules so you update your GUI on the correct threads. For those who do all operations within IStrategy callbacks, there's no issue worrying about using IContext.executeTask(...) but if you write complex "manager" objects with their own threads (like I do...), then you MUST be very careful about that, and Thread Context, plus Synchronization, of course.

The Dukascopy API engineering is First Class, Rock Solid; but your coding needs to do things in the required manner, of course. I operate with many hundreds of order operations per day, and there is almost NEVER any issue at all. It's as solid as can be... in my experience.

If you're fluent in Java and threading, you'll do just fine

HyperScalper

ah, thanks, I should have more detailled: I'm serving all financial data to browsers, (websockets etc..)
well if you want it's a remote GUI kept in sync, but very much simple for the moment, to provide users what they need.
about GUI's interface, I wouldn't substitute to broker's sofwares.
and yes, my code using JForexAPI is quite minimal, trying to do with it since today, ,just encoding received data and sending it to an erlang http-server that does the rest, (we tried Lightstreamer at first as a good alternative)