Java/J2EE to .NET (high-traffic) interoperability

[Anonymous]

A couple postings on javaranch have talked about SOAP being much less efficient (although much simpler to implement) for high-traffic applications than using another distributed RPC mechanism like RMI. Any thoughts on this which are specific to Java/J2EE and .NET interoperability? I am concerned about speed of transactions (and of course reliability) via whatever interoperability mechanism I decide to implement in my solution.
Thank you.

[Lasse Koskela]

These days, "interoperability" equals "XML in some form or the other". In other words, if you want interoperability, it comes with a cost (that being a verbose, XML-based messaging protocol).

[Anonymous]

Thanks for your response, Lasse.
Regarding interoperability between the two platforms, there are actually a couple options, two of the newer options being Bridging and Web Services (i.e. XML-based protocol).
Bridging involves .NET Remoting between the .NET application and a Bridge, and Java RMI between the Bridge and the J2EE application. I have seen a couple third-party Bridge products, but I am curious whether there are any open source Bridge projects in existence that are reliable.
One of the other more common options, of course, involves Socket communication between the two platforms, when one is not concerned about object transmission, but rather streams of data, etc.
It appears that "high-traffic application", as intended by some of the articles I read, generally involves transaction rates of approximately 1000 per second. So, basically, it appears that Web Services are not intended for such high volumes - I just need to determine what the needs are for my system.
If anyone has a different understanding on this, please let me know.
Thanks.

[Jim Baiter]

For an open source option, see IIOP.NET.

[Anonymous]

Thank you for the link, Jim. I appreciate it.
I performed a cursory review of the IIOP.NET web site, and have emailed Swiss group ELCA some initial questions regarding the expected production/stable release, as well as its thoughts on similar products such as Remoting.CORBA and Soap2Corba, etc.
Interoperability between J2EE and .NET is a relatively new topic, and the first two texts, along with some white papers, I have reviewed mainly rely on proprietary solutions, such as Ja.NET, so the fact that open source solutions are starting to appear is a good direction for the technology.
Thanks again.

[Jeroen Wenting]

using SOAP you should have no interoperability problems except perhaps performance.
Performance in SOAP is mainly a factor of the XML generation and network resources available.
The first you can test and select the SOAP engines for on either end (most offer decent performance these days), the second may be out of your control (at least on one end).
Big advantage of a SOAP solution is that you will have no trouble if either end must change to a different architecture. As long as there's a SOAP engine for the platform you are working on on both ends you can continue to talk.
By using a custom protocol you are locking yourself into 2 hardware/software platforms, something which may well be undesirable.

[Anonymous]

Thank you for your response, Jeroen,
The following is some additional information I have found while conducting some secondary research on the topic. Please be aware that the specific application for which I am currently undergoing an investigation involves communications via a SIP application server, with the Java/J2EE to .NET interface being between this server and an enterprise back-end - the interface resides within the corporation's intranet. It is known in advance what platforms reside on either side of the interface, unlike in an internet environment where an interface is desired to make its services available to various clients on various platforms.
Unlike an enterprise system, which typically involves synchronous invocations (e.g. with a database) and low frequency course-grained events, a communications system typically involves asynchronous communications and high frequency fine-grained events.
Web Services provide an excellent solution where interoperability is required across WANs (e.g. internet environments), where users employ different types of clients connecting to various types of servers. Web Services were specifically designed for exposing applications as a set of services, where it is not known in advance what kind of client is going to invoke the service, and there is no degree of control over the architecture/technology of the client.
Bridging might be considered the better solution in an intranet environment, where businesses require a reliable, high performance, scalable, and secure interoperability solution. In addition, it is applicable when development teams have control over the architecture, design, code, and technology used for various application tiers.
Please let me know whether the above comments make sense. Note that Bridging between the two platforms in question involves Java RMI/IIOP, CORBA, and .NET Remoting. Although each Bridging product, whether proprietary or open source, is constructed differently than its competitors, each is based on the CORBA standard, which has a much longer history than Web Services.
At this point, I am wondering if anybody here on JavaRanch has any experience using IIOP.NET or other similar products. Please mention whether the experience was in an academic or professional environment.
Thank you.