Develop Reference

How to send/receive data to/from MetaTrader Ternminal 4 with JAVA (or anything!)

I have been working on an algorithm ( Not mine, I am just modifying it ) that predicts when to buy and sell on the FOREX market. I need to be able to open and close orders, dynamically update parameters of the orders ( such as stoploss, maximum stop etc. ) and receive real time tick data.
I have been researching for well over a week, and have no success.
The closest I have gotten is using JavoNet and Mt4 Api
I managed to import the DLL into java and use a MQL4 function, which was AccountBalance(), however this has returned 0.0, which was not the account balance, I messed around with the code and the settings on MT4 client but still no luck.
Q0: Can anyone please point me in the right direction?
I am new to automated FOREX trading but from what I understand there is a broker somewhere with a MT4 server and I connect to that server with my MT4 client on my windows machine.
Q1: If this is the case, do I need to make an API work with the server side instead of my client side?
All these DLL's I have tried so far have been used with the MT4 client software on my machine.
I have also been doing some reading on the FIX-Protocol and ZeroMQ.
Q2: Can these help me achieve my goal in any way (instead of creating some bridges between JAVA and MT4 DLL's)?

A0: yes, forget straight about REST and synchronous, blocking chains in FX-trading domain
A1: well, not a typical way. MetaTrader Server is a proprietary suite of systems on the Broker-side and theirs API are not disclosed to allow some 3rd party integrations against.
A2: FIX-Protocol is the industry standard LP-interfacing lingua franca. In case you have contracted relations with your institutional trading provider, incl. the FIX-Protocol GWY-port, this may provide you an A-level access to the Market and to integrate your trading tools against. If this is the case, forget about MT4 instrumentation, as prime-time cadences are far beyond the MT4 Terminal localhost processing architecture ( multiple events with a sub-millisecond TimeDOMAIN resolution are common, whereas MQL4 does not provide any direct support for multithreaded-concurrent / better parallel programme scheduling designs ). FIX-Protocol events are simply off-the picture above, being far left, "before" the graph starts from 1st [ms] column.
ZeroMQ may help liberate your further designs from MQL4 limitations. May like to read my other posts on distributed systems, where MQL4 / ZeroMQ / ML-AI-predictors / GPU-processing infrastructures appear.
Anyway:
Enjoy the Wild Worlds of MQL4/MQL5
Interested? May also like reading other MQL4, ZeroMQ distributed processing and low-latency trading posts

You can try MetaApi https://metaapi.cloud cloud service which provides REST API and WebSocket API access to both MetaTrader 4 and MetaTrader 5 accounts.
Official REST API documentation: https://metaapi.cloud/docs/client
SDKs: https://metaapi.cloud/sdks (javascript, python and Java SDKs are provided as per April 2021)
It supports reading account information, positions, orders, trade history, receiving quotes, and accessing market data.
The service also provides copy trading API https://metaapi.cloud/docs/copyfactory and API to calculate forex trading metrics on a MetaTrader account https://metaapi.cloud/docs/metastats.

I started to code an expert with MQL5, naturally on MT5 platform, and I must admit that the difficulty of managing the application along with the increase of its complexity is high. It's not only due to a missing garbage collector, that of course imposes the deletion of the new instances, but also because Java offers a set of powerful data structures and syntax that MQL5 naturally doesn't have. Last but not least, talking about the community and the third party libraries available, there's a light year of the distance between Java and MQL5. I.e. if I need to find a library for a JSON conversion on the Java side I find dozens of official and stable versions, in the MQL5 community I have found only rubbish that I had to modify myself.
So, after numerous failed tries on coding my expert in MQL5 (not a simple one of course), I decided to adopt a radical approach: coding an application, client-side MQL5, and server-side Java, that provides a Java facade for the MT5 platform. Same API, same basic events and so on. Even though I thought more than once that I was getting stuck in a blind path, I kept coding and eventually, I made it, obtaining a really solid result.
Naturally, the REST interface drastically reduces the performances, and each request, even with Tomcat and MT5 running in the same localhost, is in the order of milliseconds, not micros, but on the other side this reduces only the suitability of this architecture, it doesn't make it useless at all.
Strategies like scalpelling and every kind of high-frequency trading are not good for such kind of scenario, vice-versa every other strategy in the longer period, even if intraday's ones, can be implemented successfully without any cons.
Last but not least, it isn't necessary to use the WebRequest() MQL5 method to call any Servlet container, it is possible to import the wininet.dll from the OS (talking about Windows) and the strategy tester will work as if the strategy has been coded in MQL5, maybe just a little bit slower.
To sum up, I wouldn't be so sarcastic on the Java facade approach for the FX trading platforms, citing only the nude performances without contextualizing the overall scenario is a naive approach to face the argument.

If you need to send/receive synchronous message between MT4 and Java application, REST would be the best approach because fast response matters in this scenario. Message Queue solutions like ZeroMQ fits better in asynchronous solutions, so it won't help you. Once you choose REST approach, you can use MQL4 WebRequest() to call your Java application.

WebRequest isn't the end of the world, you can submit http requests from your EA using API, works even with Strategy Tester.

In order to collect the tick information and open, update or close orders, you can use mt4 server api.
please check this url.
http://mtapi.online/#overlappable-4
Maybe you will find what you want.
And then I have also mt4 server api. If you have any questions please update me.

How to use Typesafe Akka with Node.js

I have case that needs manipulate large stream of JSON and injecting it to Apache HBase. Our system works on Node.js with Mongo then, since we needs to enhance performance so HBase is choosen to handling the big data things.
To enchance my system scalability, I prefer using Actor Model by Akka for messaging instead any other messaging queue system. It's because Actor Model that Akka provide gives me any advantages about fail safe, Actor management, and other features that's very helpful to make my job done. But it still in JVM layer that directly injecting and consuming data from HBase.
I want my Node.js apps also works under Akka system maybe using node-java. Is it good practice? If it's not, is there any solution that Node.js can communicate with Akka?
ps. my question here is about how to works with Akka and Node.js, not arguing about "why choose to use Node.js when JVM has really fast JSON manipulating library?", it's because our system are already benchmarked and Node.js was the choosen one to handling JSON manipulation. Also it's already on production stage, so migration totally from Node.js to full Scala is not our priority today.

Just to clarify, Akka implements message passing as it's concurrency model and it supports Message Queue patterns (e.g. broadcast, pub-sub). However, you'd be better off looking at MQ solutions if that is really what you need.
I think going down the path you proposed (running NodeJs with Java interop) will yield little benefit whilst adding significant complexity for the long term.
Better to look for an answer from an architectural point-of-view.
If I had to decide, I would create a Scala / Java Akka microservice that sits between your NodeJs front-end and HBase. You can get a quick Proof of Concept running (which you can back out on relatively easy).
PS. If you are committing yourself to HBase, I would highly recommend you to also look into Apache Spark, which makes taming Big Data easier.

php api vs java traversal framework for neo4j

Does anyone know whether it is better to use core java traversal api provided by neo4j or use php api for neo 4j. Would there be any limitation in terms of distribution and scalability for a large dataset if I use php. Would one be really faster than other for say more than 1000 requests per second.
Would there be any design issues that i may run into while using either of them.
I am trying to build a friends of friends relationship till level 6.
Thanks for any help!

The Java API will be faster as the PHP Neo4j library relies on REST to call Neo4j, and there will be overhead in the REST Traversal framework vs the Java Traversal framework.
Now in terms of the actual traversal, there shouldn't be that much of a difference, because by the end of the day, the actual traversal is done in Java, either by native API, or by the REST endpoint translating into Java(groovy I believe).

WPF client sided and Java server sided?

I would like to ask for some ideas regarding a scenario like this:
1) we need to build up a real time application that runs on a client. Some sort of stock trading functionality, updates pushed to few clients in different geo locations every 25 secs.
2) the data is collected and pre-processed on the server side (Glassfish/Java)
We have been discussing options and narrowed down 2 options:
1) WPF on the client
2) Swing (we previously evaluated JavaFX)
What are your thoughts on:
1) easiness/speed of development of an "medium" complex client application in Swing vs. WPF
2) communication between WPF and an app server. If we would have a monolithic solution (Java), there are more options for hight throughput data exchange like Java Messaging, without going through some .NET to Java bridges or sending data across via XML, webservices etc.
Any thoughts welcome.
Thank you

Swing vs WPF
I've done extensive work using both Swing and WPF. Swing is at least a whole generation behind WPF. There really is no comparison. WPF's data binding and templates make all the difference. You will save a lot of time and money, and end up with a much better user experience if you use WPF.
NET Framework connection to Java back end
Regarding using NET Framework on the front end against a Java back end: It is extremely easy to do and will generally perform as well as a pure Java solution. The exception would be if your main bottleneck is network bandwidth and you are serializing complex trees of objects.
As itowlson noted, WCF doesn't talk Java's proprietary binary protocols, but there are still a lot of choices that can be used to talk to Java: XML, JSON, text (REST). I generally recommend good old-fashioned XML Web Services. It takes about two minutes to set up WCF to talk to a simple Java web service.
XML Serialization typically only adds 5-10% to network bandwidth over binary, so unless you have a lot of complex data and your pipe is very tight, I would just use WPF/WCF talking directly to Java on the back end. If you do have lots of data and a tiny pipe, you still want the WPF front end because it is so much better than Swing, but you might consider using the WCF binary formatter over the wire and doing the conversion on the server.

Regarding communication between WPF and an application server, you can use all of .NET's messaging facilities, specifically including Windows Communication Foundation. However, WCF does not have out-of-the-box support for binary messaging to Java (see Does WCF play well with Java? for discouraging info) so you would need to use XML, a custom transport that could be supported on both ends (such as MQ) or a bridge.
(Can't help with the comparison of WPF vs. Swing, as I have no experience of Swing.)

Fastest(performance-wise) way to share data(not objects) between .Net & Java

I know of at least one post which has same words like this. But this is not exactly same as that post. I'm trying to work a way to "share" data between a .NET and Java application. I'm not concerned about objects, but just plain strings if u like.
I have a .NET application capturing real-time data and a Java application which has capability to analyze and work on this data. I'm looking for ways to re-use this same java app without coding it entirely in .NET.
My problem is that the data is "fairly" REAL-Time (.NET), and so has to be the analysis (Java). I can live with microsecond delays but I can't afford one second delay. WebServices, Queues (as in Messaging Queues), RDBMS are some of the options I can think of. Is there any better way?
Or has anybody got some real performance numbers for the solutions I mentioned above to select one of them? And just to get started: RDBMSs' are not "THAT" good for concurrent (connections doing) insertion/updation/reading, at least with the crude way of doing DBMS stuff. (Deadlocks?)

What are "objects" if not a mechanism for describing "data"? But I digress - I suspect I would look at a TCP socket between the two. If the data is very basic, then fine - just write directly to the stream; if there is any complexity, perhaps use something like "protocol buffers" to provide an easy way of reading/writing dense data to a stream without having to write every last byte yourself.
I think microsecond delays are going to be a challenge for any approach here... will millisecond delays do?

For completeness:
Another possible is to use Named pipes, it should be pretty quick, and I'd imagine (being a java guy I can only imagine) that .NET has native support for them. The down side is that on windows you'll have to either write a JNI extension or use a library like JNA to poke around at the Win32 API from Java.

Sounds like a local socket could do. The latency should be in low ms or less.

Depending on your program you may get some milage out of what #Cowan reports in answer to 'Any Concept of shared memory in java', his answer is: Any concept of shared memory in Java
In summary: he say's that you can use memory mapped files between two processes on the same machine. This in theory could work between .NET and java assuming .NET has some memory mapped file support.

Different machines communicate with each other by sending messages into sockets. Please check the below link for example.
Socket programming in the real world

Answers provided here are great. One idea that might be of interest, but is probably asking for more trouble than it's worth is to load both VMs in a single process (both the JVM and the CLR can be loaded within a native Windows application) and give them access to native code. Java via JNI and .Net via the mapping functions to native code that they allow.
You could also leverage native queue semaphores to wake up a thread on one side or the other when data is updated.
While JNI transitions are expense, they would probably still be faster than the native local socket implementation.

How is your Java application currently deployed? It sounds to me like you're willing to make some modification to it, so I'm assuming you have access to the source code.
I know this is a little out there, but could you compile the Java application in the J# compiler, so that your .NET app has native access to it?

You can convert your compiled java application to .NET by IKVM. After that you can change logic of your .NET application so it will not make data transfers to Java application, but just call data processing code written in Java as it were written and compiled for .NET.

There are a number of JMS servers which support .NET and Java clients. These can perform messages in under a millisecond.
However you might like to try an RPC solution like Hessian RPC or Protobuf RPC. These can achieve lower latencies and can give the appearance of direct calls between platforms. These support .NET and Java as well.