<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/wordpress-mu-1.0" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: No web services for Java and .NET interoperability?</title>
	<link>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/</link>
	<description></description>
	<pubDate>Sat, 07 Nov 2009 20:19:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=wordpress-mu-1.0</generator>

	<item>
		<title>by: vitallis</title>
		<link>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-440</link>
		<pubDate>Wed, 02 May 2007 12:01:06 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-440</guid>
					<description>People are cunning when say that SOA technology developed for Java/.NET interoperability. They forget to be precise. The SOA technology may be useful only for J2EE/.NET interoperability, i.e. for Server based products and for nothing more.</description>
		<content:encoded><![CDATA[<p>People are cunning when say that SOA technology developed for Java/.NET interoperability. They forget to be precise. The SOA technology may be useful only for J2EE/.NET interoperability, i.e. for Server based products and for nothing more.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: hliu</title>
		<link>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-438</link>
		<pubDate>Mon, 09 Apr 2007 09:59:06 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-438</guid>
					<description>maybe web service is  a obstacle of SOA.   The service provider should only know the interface, and provide an implementation for it. they don't need to provide the method(web service etc.) to access it. 

for java and .net,  there will be a container to glue them。 the java and .net are executed in the container.</description>
		<content:encoded><![CDATA[<p>maybe web service is  a obstacle of SOA.   The service provider should only know the interface, and provide an implementation for it. they don&#8217;t need to provide the method(web service etc.) to access it. </p>
<p>for java and .net,  there will be a container to glue them。 the java and .net are executed in the container.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Nico Baumgarten</title>
		<link>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-437</link>
		<pubDate>Thu, 05 Apr 2007 22:23:23 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-437</guid>
					<description>Although I see your point that web services may be used as solution to problems arising from old legacy applications somewhere running in the organisation, I cannot quite agree with your point.
In those scenarios you are absolutely right and there are for sure numerous obstacles. But I believe you miss out the large number of applications which are designed from scratch and are supporting interfaces to access or export data from outside the application's boundaries. 
I have worked quite a lot on these kinds of projects lately and I find it a great way to build interfaces to your applications and consider the exact implementations of any other application accessing this data/interface later. 
It also easily enables the cooperation of multiple companies (assuming that the choice for one language/platform is usually more or less fixed within a single organisation and since no interop problems would arise). However accross different companies the choices might be very different and a soap based interface between different parts of the n-tier enterprise solutions leave a great deal of flexibility to all participating members.

To summarize, also from my recent past experience, soap does play a vital role in Java and .Net Interoperability and not only for old legacy apps.</description>
		<content:encoded><![CDATA[<p>Although I see your point that web services may be used as solution to problems arising from old legacy applications somewhere running in the organisation, I cannot quite agree with your point.<br />
In those scenarios you are absolutely right and there are for sure numerous obstacles. But I believe you miss out the large number of applications which are designed from scratch and are supporting interfaces to access or export data from outside the application&#8217;s boundaries.<br />
I have worked quite a lot on these kinds of projects lately and I find it a great way to build interfaces to your applications and consider the exact implementations of any other application accessing this data/interface later.<br />
It also easily enables the cooperation of multiple companies (assuming that the choice for one language/platform is usually more or less fixed within a single organisation and since no interop problems would arise). However accross different companies the choices might be very different and a soap based interface between different parts of the n-tier enterprise solutions leave a great deal of flexibility to all participating members.</p>
<p>To summarize, also from my recent past experience, soap does play a vital role in Java and .Net Interoperability and not only for old legacy apps.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Vitaly Shelest</title>
		<link>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-439</link>
		<pubDate>Thu, 05 Apr 2007 17:53:21 +0000</pubDate>
		<guid>http://tssblog.blogs.techtarget.com/2007/03/08/no-web-services-for-java-and-net-interoperability/#comment-439</guid>
					<description>In most articles on Java/.net interoperability authors focus only in Web means used to integrate Java and .NET modules. Others suggest using some mediators like CORBA and various sorts of Java/.NET bridges. But no one discusses option of in-process integration Java code with .NET. This can be done by substituting regular JNI with JNI for .NET – Java native modules should be written in any .NET language. Where Java native methods are implemented with .NET methods, .NET JNI should hide all low-level calculations with Java references, memory allocation, Java error processing, etc.</description>
		<content:encoded><![CDATA[<p>In most articles on Java/.net interoperability authors focus only in Web means used to integrate Java and .NET modules. Others suggest using some mediators like CORBA and various sorts of Java/.NET bridges. But no one discusses option of in-process integration Java code with .NET. This can be done by substituting regular JNI with JNI for .NET – Java native modules should be written in any .NET language. Where Java native methods are implemented with .NET methods, .NET JNI should hide all low-level calculations with Java references, memory allocation, Java error processing, etc.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
