<?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"
	>
<channel>
	<title>Comments on: Today, Portability Matters More Than Ever</title>
	<atom:link href="http://blog.springsource.com/2008/04/29/today-portability-matters-more-than-ever/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.springsource.com/2008/04/29/today-portability-matters-more-than-ever/</link>
	<description>The voice of SpringSource</description>
	<pubDate>Sun, 12 Oct 2008 08:55:28 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Juergen Hoeller</title>
		<link>http://blog.springsource.com/2008/04/29/today-portability-matters-more-than-ever/#comment-104862</link>
		<dc:creator>Juergen Hoeller</dc:creator>
		<pubDate>Wed, 30 Apr 2008 23:04:39 +0000</pubDate>
		<guid isPermaLink="false">http://blog.springsource.com/main/2008/04/29/today-portability-matters-more-than-ever/#comment-104862</guid>
		<description>Well, yes - bytecode portability, that is :-) Portability of components in an enterprise service environment is arguably a quite different affair at a significantly higher level. It's about ties to specific deployment units, deployment services, runtime services - and how much of your code is affected there. Of course this requires some careful architectural design in the application as well, but the nature of the fundamental component and configuration model already makes a big difference here.

J2EE's track record isn't great in that respect, at least for EAR files. The use of Spring within a WAR file constitutes a significantly better basis here. This is what we're hearing from our users who attempted such migrations between different application servers, or even simply between different generations of the same application server. People also appreciate that Spring's full-fledged Java 5 component model is available on J2EE 1.4 servers such as WebLogic 9.2 and WebSphere 6.1...

Juergen</description>
		<content:encoded><![CDATA[<p>Well, yes - bytecode portability, that is <img src='http://blog.springsource.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> Portability of components in an enterprise service environment is arguably a quite different affair at a significantly higher level. It&#039;s about ties to specific deployment units, deployment services, runtime services - and how much of your code is affected there. Of course this requires some careful architectural design in the application as well, but the nature of the fundamental component and configuration model already makes a big difference here.</p>
<p>J2EE&#039;s track record isn&#039;t great in that respect, at least for EAR files. The use of Spring within a WAR file constitutes a significantly better basis here. This is what we&#039;re hearing from our users who attempted such migrations between different application servers, or even simply between different generations of the same application server. People also appreciate that Spring&#039;s full-fledged Java 5 component model is available on J2EE 1.4 servers such as WebLogic 9.2 and WebSphere 6.1&#8230;</p>
<p>Juergen</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jan</title>
		<link>http://blog.springsource.com/2008/04/29/today-portability-matters-more-than-ever/#comment-104796</link>
		<dc:creator>Jan</dc:creator>
		<pubDate>Wed, 30 Apr 2008 07:06:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.springsource.com/main/2008/04/29/today-portability-matters-more-than-ever/#comment-104796</guid>
		<description>Portability comes from Java not Spring :-)</description>
		<content:encoded><![CDATA[<p>Portability comes from Java not Spring <img src='http://blog.springsource.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
</channel>
</rss>
