<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Our vision of Java/.NET interoperability</title>
	<atom:link href="http://www.jnbridge.com/jn/blog/2009/11/12/our-vision-of-java-net-interoperability/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jnbridge.com/jn/blog/2009/11/12/our-vision-of-java-net-interoperability/</link>
	<description>Java and .NET Interoperability</description>
	<lastBuildDate>Tue, 04 Oct 2011 13:21:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Tony Baer</title>
		<link>http://www.jnbridge.com/jn/blog/2009/11/12/our-vision-of-java-net-interoperability/comment-page-1/#comment-18516</link>
		<dc:creator>Tony Baer</dc:creator>
		<pubDate>Fri, 13 Nov 2009 17:27:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.jnbridge.com/blog/?p=88#comment-18516</guid>
		<description>I would certainly concur that web services is not synonymous with Java/.NET interoperability. The web services stack form of SOA is itself a fairly complex buffer tier arhcitecture that has its own interoperabity issues.

That said, SOA, whether it be web services or looser RESTful architecture, makes sense where the connection should be more loosely coupled. That is, where the source or target systems for the transaction are likely to change or be replaced by other systems or applications. On the other hand, if we are talking about a dedicated, foundational transaction where the connections are not likely to change and where performance considerations ar paramount, there is no substitute for direct transactional interoperability.</description>
		<content:encoded><![CDATA[<p>I would certainly concur that web services is not synonymous with Java/.NET interoperability. The web services stack form of SOA is itself a fairly complex buffer tier arhcitecture that has its own interoperabity issues.</p>
<p>That said, SOA, whether it be web services or looser RESTful architecture, makes sense where the connection should be more loosely coupled. That is, where the source or target systems for the transaction are likely to change or be replaced by other systems or applications. On the other hand, if we are talking about a dedicated, foundational transaction where the connections are not likely to change and where performance considerations ar paramount, there is no substitute for direct transactional interoperability.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

