Java/.NET Interoperability: Web Services Aren't Always the Answer
Mixing .NET and Java technologies with web services is often easy, but for many tasks web services are not the solution for Java/.NET interoperability.
by Wayne Citrin
October 22, 2009
eb services can be very useful for integrating standalone components that communicate across a network. When used with straightforward call/return scenarios involving a very limited number of data types, setting them up and getting them to work is trivial. Because web services are standards-based, mixing .NET and Java technologies with them is also easy, which leads some people to believe that web services are the answer to the question of Java/.NET interoperability. They often are not.
A simple web search on "Java .NET interoperability" will return many different approaches, but anyone who heard the Microsoft keynote at JavaOne 2009 this past June may have come away believing web services were the best way. This is unfortunate, because for many tasks, web services are not the ideal Java/.NET interoperability solution. For some tasks, using web services is simply impossible. In this article, I identify three scenarios involving Java/.NET interoperability for which web services would be an unwise choice.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
eb services can be very useful for integrating standalone components that communicate across a network. When used with straightforward call/return scenarios involving a very limited number of data types, setting them up and getting them to work is trivial. Because web services are standards-based, mixing .NET and Java technologies with them is also easy, which leads some people to believe that web services are the answer to the question of Java/.NET interoperability. They often are not.
