When it comes to web services interoperability between .NET and Java, the choice used to be limited to SOAP over HTTP. This became even more limited with introduction of .NET 3.0 because only BasicHTTP binding in .NET provides direct interoperability with Java Web Services.
Two new options recently became available in this area – WebSphere MQ (WMQ) and ActiveMQ transports can now be used for building interoperable web services between Java and .NET. Moreover, reliable messaging for .NET is now extended. In addition to MSMQ, both WMQ and Active MQ can now be used as reliable transport for .NET Web Services.
The WMQ solution is based on the Custom Channel for IBM WMQ for Windows Communication Foundation available from IBM’s AlphaWorks, with a new version posted on March 14th. This product enables WMQ to be used as a custom channel within the Windows Communication Foundation (WCF) framework (as available in the .NET Framework 3), in the same manner as the built-in channels offered by Microsoft.
Messages are formatted according to the SOAP over JMS implementation available in WMQ v6.0, enabling applications to communicate both with services hosted by WCF or by the WebSphere SOAP over JMS service infrastructure, including WebSphere application server and CICS.
The current implementation is intended as a proof-of-concept to help better understand the product requirements in this area (and is not suitable for use in a production environment). The plans for productizing this implementation are not yet finalized.
The custom channel is built using the extensibility framework provided within the Windows Communication Foundation, which allows it to be integrated and used within the framework in the same way as the built-in transports offered by Microsoft. Service applications can be configured to use the new custom channel in the normal way, with client application being generated using standard tools such as the Microsoft Service Metadata Utility Tool (Svcutil.exe). Service metadata descriptions can either be published directly from a running service (provided it is exposed via an additional HTTP endpoint) or using WSDL (Web Service Description Language).
The current implementation supports the core messaging functions with the following restrictions:
- Support for only one client per service instance for Duplex channel shape.
- Duplex channel is an extension to the SOAP/JMS implementation provided by WebSphere MQ v6 and as such is only for use between WCF services and clients.
- Core messaging features only (i.e. no support for more advanced functionality such as transactionality or security)
- Interop with SOAP/JMS services hosted by the existing SOAP/JMS environment in WMQ v6 (using either the .NET or Java/Axis listeners) is restricted to one-way operations.
- Interop with SOAP/JMS services hosted by the SOAP/JMS environment in CICS or WebSphere Application Server does not support mixing one-way and request/reply operations within a single contract, a separate contract must be created for each channel shape.
The Active MQ solution is based on the Axis provider for JMS (in Java) and the “pluggable protocol” feature (in .NET). As such it is not packaged as a true .NET custom channel requires more custom programming.
Neither solution is fully productized, but both provide a good base for experimentation with alternative web services interoperability transports.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/asp-dotnet-minimal-apis/en/smallimage/logo-1678972581766.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/articles/functional-dotnet-development/en/smallimage/Fsharp-vs-Csharp-is-one-more-functional-than-the-other-small-1676023056578.jpg)
/articles/dotnet-grpc-json-transcoding/en/smallimage/logo-1674822319367.jpg){kind=logo}
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/Dotnet-Seven-MSMQ-Alternatives/en/smallimage/logo-1670585778128.jpg){kind=logo}
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/presentations/java-shared-memory-files/en/smallimage/peter-lawrey-s-1669107216422.jpg)
/articles/josh-long-spring-6/en/smallimage/logo-1669141674434.jpg){kind=logo}
/presentations/devops-java-devs/en/smallimage/Ix-chel Ruiz-s-1669107288266.jpg)
/presentations/log4shell-security/en/smallimage/Simon-maple-s-1665986617483.jpg)
/presentations/loom-java-concurrency/en/smallimage/Tomasz Nurkiewicz-s-1665739004716.jpg)
/articles/polygot-microservices-dapr-aks/en/smallimage/logo-1666079703389.jpg){kind=logo}
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
Community comments
Interop with .NET 3.5
by Arnon Rotem-Gal-Oz,
Re: Interop with .NET 3.5
by Christian Schneider,
Re: Interop with .NET 3.5
by Stefan Tilkov,
Re: Interop with .NET 3.5
by Vitaly Shelest,
Interop with .NET 3.5
by Arnon Rotem-Gal-Oz,
Your message is awaiting moderation. Thank you for participating in the discussion.
Actually, it is now much easier to interop between .NET and Java as .NET supports RESTful services
and you can use http, atom etc which are ubiquitous (you can take a look at a short post I made on the WCF REST options)
Arnon
Re: Interop with .NET 3.5
by Christian Schneider,
Your message is awaiting moderation. Thank you for participating in the discussion.
Simply connecting .Net and Java with Webservices is no big deal. When using http it works out of the box. What this article talks about is using a message oriented middleware to do the connection. This has many advantages over http. For example you can have clustering for free by simply listening with two instances on the same queue. Another advantage is location transparency. When you use http you always have the server name in your url. So when you move your service from one server to another you have to adjust the url in the clients. When using a queue you can simply start an instance of the service on any machine and the clients can connect to it.
Re: Interop with .NET 3.5
by Stefan Tilkov,
Your message is awaiting moderation. Thank you for participating in the discussion.
Of course nothing stops you from introducing one level of redirection in the HTTP case, too - either via a registry or through a simple "service document" containing links to the actual resources (or endpoints, if you prefer).
Re: Interop with .NET 3.5
by Vitaly Shelest,
Your message is awaiting moderation. Thank you for participating in the discussion.
Such articles that describe .NET/Java (SOA, JMS, MSMQ, WEB, SOAP,etc.) interoperability should be titled as ".NET/J2EE ineroperability". This is a very specific case of .NET/Java interperability that has very huge overhead.