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.
[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.]