The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

how can C# code interact with Java?

We have a legacy java application, which does a lot of work, and is not easy to convert to .net. Our new project is in C# & .NET (everything desktop based).

To simplify it, lets say that the Java code has capability to query in a specialized database and return large amount of data.

what would be the best practise for us to get this data in .NET?

Is remoting possible between .net & Java?
Or should they transfer data using SOAP / some sort of web services?
Or something completely different?

Everything runs on same machine.

Thanks a lot for your time.
Don Hust
Wednesday, July 18, 2007
You probably can't afford to fire up the JVM for every request so you need a long-running Java program waiting for requests to service.

If your throughput requirements aren't too insane, I might just do something dead simple like drop requests as XML files into a directory and return the results in similar fashion. The Java and C# programs just monitor the directories for new files.

If this doesn't cut it, you can work your way up the complexity ladder with signalling events, anonymous pipes, sockets, RMI, web services, etc., etc.
Mike Stockdale Send private email
Thursday, July 19, 2007
The problem consists of two parts:
1) transport mechanism
2) serialization

Transport mechanism should probably be raw sockets.

You probably don't really want your Java component to be a web server and implement HTTP, do you? HTTP was not really developed with RPC in mind so you are not gaining anything.

There are of course other mechanisms. I'd just instinctively go for raw sockets.

For serialization, if you prefer XML you should consider XML-RPC rather than SOAP. Overhead and learning curve is much lower, it's well defined (unlike SOAP with a billion dialects) and it "just works".

Another option is doing your own serialization. May be more efficient for your data. And may well be easier than finding two appropriate and compatible libraries, learning, and setting them up. And it's definitely more fun.
Yury @ Xtransform Send private email
Thursday, July 19, 2007
Have you looked at J#:
I've never used used it so I don't know how difficult/easy it is to convert existing Java code to it. Still, may be worth a look.
Dan Shappir Send private email
Thursday, July 19, 2007
Have a look at JuggerNET which is a tool dedicated to solve that kind of problem.
I have never used it so I don't know if it's any good nor Do i know if there are any competitor to that product.
Monkeyget Send private email
Thursday, July 19, 2007
Yury why wouldn't SOAP work.
We develop a .NET web service that sends large amount of data (>100KB) as xml parameters. I test it using soapui a Java SOAP test tool. It just works.
Thursday, July 19, 2007
That transport / serialization breakdown is right on the money. I'd probably go for raw sockets just because it's so easy and relatively language independent. HTTP is fine too if you find a small enough HTTP server. I wrote one for a Wiki and it's only a handful of classes but pretty high effort.

If you're considering XML, also consider JSON. It's a little more compact and the parser / generator tools are lean, too. I'm using Frank Carvers StringTree JSON in Java.

A little off the wall: I used a language called EASEL (still in business as ESL) that talked to the stdin and stout of external modules. Their SQL integration was seriously something like:

Process p = new SQLModule()
p.send( sql statement ) <- SQL program reads stdin results ) <- SQL program writes stdout

After all that, I would not be shocked to find somebody has already solved this. google thoroughly before writing anything. :-)
Stan James Send private email
Thursday, July 19, 2007
Careful with a TCP socket solution.  Unless you can arrange persistent connections and reuse them you'll run out of ephemeral ports for new client connections fast if you have any real volume of cross platform communication going on.

Sockets != IPC for serious applications.
Thursday, July 19, 2007
"Careful with a TCP socket solution.  Unless you can arrange persistent connections and reuse them you'll run out of ephemeral ports for new client connections fast if you have any real volume of cross platform communication going on.

How would this be different compared to say, IIS running out of ports?
Anon Send private email
Thursday, July 19, 2007
You cold also look into queuing technology like MSMQ, MQ Series, or SQS. It has it's pros and cons compared to the other methods people pointed out. The big con, depending on your setup, is that it's asynchronous so will be a bit slower and trickier if you need to wait for a reply. The pro is that is can help with scalability and fault tolerance (although it introduces a potential point of failure as well).
Eric Marthinsen Send private email
Thursday, July 19, 2007
I worked on a project that used SOAP to connect a .NET client to Java code running on a server.  It was very simple and straightforward to implement on both sides.  The main issues are whether it's worth it to be bothered with having a dependency on a web server and whether your app has performance needs that the overhead of SOAP might get in the way off.
SomeBody Send private email
Thursday, July 19, 2007
If you do decide to use JSON over sockets, I've written a JSON serializer for .NET that you might find useful.  You can  find the project on google:
Send private email
Thursday, July 19, 2007
Launch the Java program from the C# program and have the C# program capture the stdin and stdout of the Java program. They then communicate through the standard IO mechanism. For example, the Java program uses System.out.println to send something to the C# application and the C# application calls Console.Readline to get the info.

This works just fine on the same machine. However, I would personally just go the sockets route because if you ever need to run the Java app on a different machine then you are all set to go. At the very least, encapsulate the communications logic so that you can support multiple transport mechanisms.

You might also look at how other products have done this. When on the same machine, many products use shared memory or named pipes for IPC.
Sunday, July 22, 2007
dippin' dots
Sunday, July 22, 2007
I've seen the stdin/stdout solution used before for large volumes of data and it works fine. A visualisation tool written in java received input and wrote output using this technique  - it is totally compatible with any language. It also takes about 30min to write - a very simple application wraps your classes with a simple IO layer.

Simplicity is key here. Try the easiest and see if it is good enough. I'd definitely try the console IO foirst, or the idea of communicating by saving files which the application polls for.

Thursday, July 26, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz