What you are trying to do is define a method for IPC, or inter-process communication. There are many, many ways to do this.
In general, the best methods for IPC provide the following benefits:
- Standardized, so other developers can look at your code and understand it.
- Robust, including error-detecting mechanisms.
- Supported by your platform (OS, programming language, etc).
- Simple, requiring little to no framework-level code on your part.
For these reasons, I typically pick TCP/IP.
- It is heavily standardized and everyone should know how it works.
- It has built-in error-detection and ACK mechanisms.
- Supported by virtually all modern platforms.
- Most library implementations are simple: provide endpoint information, get a stream.
- Your client and server are currently on the same machine. If future requirements change this, all you need to do is change your connection info and it will still work just fine.
As far as the payload of the TCP/IP communication, that can be anything you want: XML, JSON, serialized objects, whatever is convenient. Typically when mixing languages, however, I would go with something like XML or JSON which are platform-agnostic and human-readable (aids with debugging).
I also highly recommend writing test cases where you can plug your stream into a mock that produces or consumes data. That way you can test your interface on both ends without needing a full client/server system up and running.
Do not communicate using files unless there is literally no other way. I want to keep this answer short and to the point, so I will say this. I have worked with interfaces that were file-driven. I hated it each time, and always asked if there was a different way to do it. This is error-prone and klunky.