views:

489

answers:

7

I have one SDK that is available in Java and another SDK that is available for .Net and would like to write a single application that interfaces with both of them. I imagine I will need to use a cross platform communication framework that can support named pipes (or other in memory communication), what is the best choice?

After some more research I found Hessian -- does anyone know anything about the maturity of this project?

A: 

you can use WCF in .NET.... but.... its not the best for consuming a native SDK from another language..... services kind of need their own type of design.

You can use COM also, thats not TOO bad, still a bit painful.

Depends how desperate you really are to stitch the two languages together

Keith Nicholas
Well, the current project is a data importer, so it could really be written as two separate applications. However, it would be a useful technique to know in general.
Luke
+1  A: 

Well, there are a few options here:

  • Communicate between the two somehow. If you need to pass data structures around efficiently, I can thoroughly recommend Protocol Buffers, but I'm biased. Please help to test the C# port :) This is probably the cleanest and simplest approach.
  • Host the JVM and the CLR in the same process and use JNI/PInvoke to call between the two. Sounds icky to me, but Eclipse somehow manages it with the WPF frontend. (I don't know that project's current status, admittedly.)
  • Use IKVM which is designed for this kind of situation, but may have some limitations. (I haven't used it myself.)
Jon Skeet
+1  A: 

The "standard" option is to use Web Services for this. The JAX-WS frameworks in Java are built with .NET interoperability in mind, so that .NET's WCF and Java should play along nicely.

If you need more performance than Web Services can provide, I would look at tools like Hessian or the super cool and rising star Protocol Buffers from Google. :)

Guðmundur Bjarni
I suppose in my current project the data is going to cross a network boundary anyway, so a local loopback connection would be a negligible performance hit. I am definitely still interested in an in memory solution though.
Luke
A: 

ESB (its more than a buzzword), you could for example do client in .NET that check if user and password are correct in Java. Its all Message(JMS/WebService) based, i think JBossESB is one of the easiest one to use, checkout it examples.

01
+2  A: 

Depending on your architecture (strongly or loosely coupled), you have several options:

1) Hessian: fast and works well between c# and Java (Java service deployed using Spring and Tomcat, C# client). Don't forget that Hessian is basically an interoperable version of Java RMI without the pain - RPC all the way down. Works on MS CLR and Mono 2.

2) IKVM: Strong coupling, you effectively run your Java SDK in .NET without having to recompile. IKVM is pretty mature, having integrated work from the OpenJDK. Works on MS CLR and Mono 2.

3) Web Services: Loose coupling, expose portions of each SDK as Web Services, integrate as you please. Lots of fun work to be had here for little immediate value.

Don't forget you can have a play with each of these approaches - nothing like getting your feet wet and learning in the process.

HTH

Rowland

+1  A: 

I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.

Pavel Savara
A: 

I'm going to recommend two more just because nobody listed them yet:

  • Network Sockets (possibly localhost only)
  • UNIX domain sockets
Joshua