.Net Framework号称是分布式运算产业的下一波重点。
由于是全新设计，微软这项技术在部分领域上显然有明显进步，如XML整合、错误处理、组件处理，和可重复使用的架构等方面。Web开发的未来十分明确：更快的开发、程序可少写一些、稳定性会更好。
但是如果你目前的应用软件是用Java EJB(Enterprise JavaBeans)写出来的呢？将这些软件移植到微软新平台值得吗？.Net与Java EJB哪一个比较优秀的话题未来一定还有得吵上一阵子，但这类平台转移的困难度却比较容易预测。即使你有非常迫切的技术或商业原因必须作转换，以下还是有五大理由奉劝你不要轻言将Java或J2EE程序转到.Net平台上。
1. CLR不支持Java
转移至.Net的第一个障碍就是它所支持语言。.Net架构是靠着Common Language Runtime (CLR)来实现多语言的兼容性，但是这个兼容性目前只限于C#、C++、VB和(即将加入的)J# 。而一点也不令人意外的是，Java并非CLR所支持的程序语言。
要将Java应用程序转移至.Net但又无须以CLR支持的语言重新撰写程序的确是有可能，只需透过Java COM转换程序或Web services(网络服务)即可。然而，Java COM却需依赖第三方软件才能从Java程序代码建立COM DLLs。但这方面在尔后的除错过程会相当困难，同时也增加了环境的复杂度，因此要处理这类异质应用开发必须非常小心，甚至建议不要采用。
另一种策略就是将Java程序代码转换为C#程序代码。理论上，你可以利用自动化程序将Java码直接转成C# (与J#)语言。例如，ArtinSoft公司的Java Language Conversion Assistant Enterprise Edition (JLCA EE)号称可将Java转成C#语言，正确率高达99%，但这样的产品还没有经过市场验证，且经验法则也会告诉你最好不要信任自动转码机制。不管是使用自动转码方式还是透过手动，语言转换总会涉及架构转变的问题。当你将Java程序改成VB、C++、C#或J# 后，程序中也将会有许多地方必须重新调整(依据应用程序的设置规格而定)。
服务器控制太麻烦
2. IIS不支持JSP
若你认为只要将程序语言从Java改成C#就大功告成，那就错了，.Net还会要求连同呈现(presentation)语言也要一起转换，IIS并不支持JSP。从JSP转换成ASP.Net绝对是一项大工程，且你必须完全重写presentation层不可。另外，许多重要的架构模式在ASP.Net下也不支持，例如透过卷标库的程序代码再利用即是一例。卷标库必须转换成服务器控制或是服务器端的includes(ssi)。有意思的是，支持卷标库的Java classes在概念上正好与.Net的程序代码后置(code-behind)classes相当，但实际转换还是需要花上许多功夫。
3.服务器控制需要重新设计
之前提过，在对.Net的程序代码进行语言转换时，新的架构需求一定也会跟着浮现。这在计画.Net服务器控件(server controls)的实作时更是明显。ASP.Net服务器控件是.Net的最大优势之一。开发人员可利用预先建立的服务器组件，降低重复性的程序撰写，且可轻松透过对象存取各项功能。若希望转换成.Net平台后也能使用服务器控件的好处，你势必要移除许多客制化的呈现层、应用程序与数据库程序代码，并全部改成服务器控件以及所需的数据库逻辑。
若你是从既有的微软应用程序作升级，此一程序代码的抽取(extraction)并不困难，特别是之前你有良好的程序撰写习惯的话(分割明朗，条理分明)。然而若是从Java EJB程序作升级时，服务器控件则会动到非常深入的垂直转换，同时将影响到资料、应用程序、以及程序的呈现层。所有之前储存的程序、Java对象，和JSP文件都必须转换成微软支持的标准，同时还需经过修改才能支持Server Control。
例如，DataGrid对象可复杂的表格功能来呈现资料记录。部分可由使用者自行控制的选项包括行列选择、头标样式以及呼叫(paging)功能等。DataGrid对象比任何客制化或是专属程序代码的功能都更强大、维护也更容易。但若Java应用程序转换后（假设你要从Oracle资料层转往SQL Server），要利用此一控制选项的话，你需要：
‧将P/L SQL重写成Transact SQL，并将查询重新格式化以支持DataGrid。
‧将Java程序代码改成.Net所支持的语言以便取出SQL或预存程序，并支持DataGrid的事件模型。
‧移除支持现有客制化的呈现对象，并将JSP模板重写成ASP.Net。
从头至尾 困难重重
4.不支持CMP容器管理永续性
假设现有的Java程序是由非SQL Server数据库所支持，那么移植应用程序之后，你还得同时将数据库转移至SQL Server上，或者安装驱动程序好让.Net应用程序能经由非SQL Server数据库保持资料持续性。不管哪一种情况，你都必须将JDBC连接类改写成ADO.Net，并将Java ResultSets移植到ADO.Net DataSets。这项工作本身并不特别困难，DataSets和ResultSets具有相似的机制，除了实作规格外并不需要动用到架构重建。
不过当开发团队将对象永续(object persistence)从Java转换到.Net时，问题就会开始出现。.Net并不支持Container Managed Persistence (CMP：容器管理永续性)，也没有类似的机制。如果你的程序是靠着CMP来保持对象的永续性，你就必须以内嵌式逻辑重写撰写对象类别才能进行资料撷取与加载。
5.不同的session处理实作
EJB标准并不指定session资料的处理，所以EJB session处理实作变成完全与应用服务器有关。由于在不同的session处理实作攸关性能表现、扩充性与网络设计，因此你必须对应用软件中的session-handling机制细节有完全的了解。
在.Net之中，微软则采用一种分布式session模型，它通过Microsoft SQL Server存储应用软件的状态，使得session资料同时分配给同一网络机房中的多个应用软件服务器。由于.Net依靠SQL Server中的内嵌功能来做session，因此使用Oracle或是其它非SQL服务器数据库的不同类型应用软件，都必须建置一个SQL Server instance只为了当作分布式sessions之用。此外，由于大量的session资料将会降低系统总体性能，因此session储存也必须谨慎使用。
转移难度高 成效顶多平手
.Net Framework代表着微软进军高可用度、企业级应用程序领域的最新成果。以往在IIS、Visual Studio、VB和SQL Server中所缺乏的功能都可在新平台上找得到。微软的开发者和用户现在终于不会矮人一截，不论在扩充性、沿展性、安全与性能上都可与业界对手平起平坐。
关键问题是，.Net与EJB解决方案供货商之间顶多打成平手，没有任何迹象显示.Net平台优于WebSphere、WebLogic、或任何其它EJB应用软件服务器。对于既有的IIS/ASP解决方案，转移平台的效益再也明显不过。而对于从头开始的新计画，.Net也可算是架构平台的一时之选(端视员工技能与企业偏好)。但是对于既有Java EJB应用软件而言，一动不如一静，因为即使你辛苦地转换了老半天，到头来发现两者其实并无差异。
Godfrey Baker原著
