I was looking through the online library at Microsoft and found this piece from John Rymer at Forrester Research - it is entitled "Choosing The Best Option For .NET-Java/J2EE Interoperability" and covers how to select the right .NET-to-Java interop technology, among the myriad options available.  Check it out if you have a relationship with Forrester.

Nothing really surprising in that document; it does not diverge from the views I have been spouting here for some time.  The piece is from January 2006, so nearly a year old, but it provides good solid guidance on the options and where they apply best. 

Stay well,

-Dino

[Update 3 January 2007 - in response to a comment asking for the highlights of this piece - sheesh, what was I thinking?  How could I have left that out.  I sort of alluded to it but if you haven't been a regular reader then you wouldn't know, would you?  My take on the highlights: 

  • Web services are best for loose coupling (which is best for flexibility - dino's comment). 
  • Web services won't do when very low latency is a requirement - essentially when in-process integration is a requirement. 
  • "Bridging middleware" can make sense for special circumstances.  (dino's comment: for example, when you already have IBM MQ installed, use it!)  

By the way, I would also like to direct people to this older, but still relevant paper on .NET-and-Java interoperability.  It discusses various options and when you might want to use each.]