.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原著